You are not logged in.
Pages: 1
Hi
I have a need for being able to use runtime defined properties.
I have a "workbase" containg all the objects converted/imported from different sources of the customer's database. (10M+ objects)
Imaging objects like transformators, power lines and switches.
SOme attributes are shared (eg manufacturer) and some attributes are not (like inner diameter, cooling oil and length).
Is it possible to use Mormot to define properties at runtime for my objects, or should I create a (SAP like) data model with an object table, attribute definition table and attribute values table.
The core problem here is that the attributes can be of different types, which are defined/known at runtime only.
IMHO The SAP solution for this is not so good: they use a single attribute value table with different columns for each value type. Apart from that, having an average of 30 attributes per object would result in a single attribute table of 300M+ records of which usually only 1 of 20 fields is filled out.
What would be the best practice to solve this with mORMmot?
Kindest regards
Hans
Offline
The mORMot ORM expects fixed properties, defined in a TSQLRecord based classs.
They are mapped as database columns, so one column per property.
So the mORMot native design of your data structure could be to define a hierarchy of TSQLRecord, with shared properties in the parent classes.
That is, you define the shared properties only one for the parent, then child classes will have custom properties.
Since our ORM understands inheritance, parent properties will be "re-used" in child classes.
See how the data model of our Main Demo works: this is exactly the case. Consult the SAD document about the Main Demo, and also see the FileTables.pas unit.
But if I understand correctly, all your objects are in the same list, right?
There is no direct way of using mORMot in this case.
One efficient way of implementing it could be to create shared attributes as TSQLRecord properties, then use a dynamic array of Name/Value pairs or even Values with a fixed index for the custom attributes.
The dynamic array will be stored as BLOB, so it will be very efficient with SQLite3 storage engine, but perhaps not so optimized for other kind of database engine.
See the documentation about how to create custom SQL functions for efficient search within the dynamic-arrays BLOBs content.
IMHO the first attempt (hierarchy of classes) is much better in your case, if you can split your objects into several tables.
Offline
FOA - thanks for the quick reply.
1) Yes we will defnitely use object inheritance. But this inheritance is to be dynamic too.
2) Objects of the same class will all have the same properties, so these "dynamic" properties need to be defined somehow with the object type.
Rethinking this, I'll probably need to translate my current (RDB) metadata model into a usable Object class model that reflects all the aspects I require.
Then I can use these objects from within the ORM "normally".
If I come up with anything better I'll let you know.
Regards - Hans
Offline
Pages: 1