How to adapt this flow to hashtables extension?

I have a context where I have two lists that come from different places, one from outsystems db (Room entity) and other lists that comes from an external source (GetRoomData SQL). So there are two lists in memory and I need a way to join a list to another in memory, 1 table is outsystems (Room that is used in GetRooms aggregate) other data comes from external source (GetRoomData). To solve this I can use one foreach inside a foreach with an if (if the RoomId in a list is equal to the RoomId in another list I get the current and do the assign and insert SQL and then to the some to the next result. In this case, I'm using a foreach and a ListFilter. 


Code flow:


Code explanation:

I have the GetRooms aggregate then I have a foreach GetRooms.List to save the each RoomId in a local variable RoomIds.


After the foreach there is a SQL query "GetRoomInfo" that gets info from an external database about a specific RoomId, so in the query is used the in operator, where the "RoomID" is in the parameter @RoomIds (RoomIds local variable).


Then I have a foreach to fetch the "GetRooms.List" and a ListFilter to fetch the "GetRoomInfo" with a condition, If the RoomId in a list (GetRooms) is equal to the RoomId in another list (GetRoomData) I get the current and do the assign and the insert SQL, and then to the same to the next result. 


Doubt:

 Do you know how to adapt this example to hashtables? I already have the server actions createHashTable, add, get and containsKey but I'm not understanding properly how to use these server actions to adapt this example to hashtables. 

Hi Ken,

The difficulty here is in order to use a generic hashtable of entities or structures, the value of the hashtable must be an object.  But there is no supported way to convert an object back into a structure or entity in order to work with it.

However, there are options, lets explore them.

One, unsupported, way would be to pass the object to an extension, use reflection to determine the properties of the object and construct another entity or structure, copy the values to it and return it.  However the extension cannot reference types from other modules, so the definition for the entity or structure you use as a return parameter must be in the extension.

Now, defining the entity in the extension only works if the entity is a from an external database, so not really that useful.

But defining a structure would work.  Note that if the structure has the same attributes as an entity, you can assign the structure directly to the entity.  And while the structure needs to be in the extension the entity you assign it to doesn't. Its kind of like "duck typing".

So if you define a structure in an extension and use that for your advanced SQL, you can also expose hash actions from the extension with the structure as the value.  So you don't even have to use the unsupported reflection idea.  You can then use a dictionary/hashtable inside the extension and return a reference to it as an object.

Of course, this means writing a specific version of a hashtable for a single type.  So for every different type you need to create a separate hashtable.  So not very extensible.  Potentially you could put them all in the same extension, which then pollutes the extension with knowledge of other domains at the expense of keeping the hashtable implementation in one place. So lots of design tradeoffs, but still a way to achieve the performance of a hashtable on the platform.

(Apologies I'm going to get a bit C# technical here, so bear with me, I can explain further if required)

Now when I have returned a reference, such as the reference to the C# dictionary, I usually generate an internal key, use a static cache to store the actual object, and return the key instead of the object reference, as I am concerned returning a reference as an OutSystems Object may release the C# object to garbage collection.  I haven't checked whether it is safe to just return the C# object reference as an OutSystems Object just yet.

I hope this helps!

Kind regards,

Stuart