Unique instances / singletons

[ayoze]

Hello,
I would be interested in preventing duplicate objects when querying the DB, for example, let's say I have a Department model and a Person model with a pointer to Department.
In database:

Person A with pointer to Department D1
Person B with pointer to Department D1
Person C with pointer to Department D2

It would be great that the A.department and B.department pointers are THE SAME object (literally, in memory) so if I update it, it will be updated anywhere in my app.

Any ideas ? Many thanks in advance

[editfmah]

Hi @ayoze,

That was a deliberate design choice for the ORM, being that we actually found that feature highly annoying. So instead we have the domain system.

So if you have Department Object a & b, and they point to the same record in the database (e.g. have the same PK), then you can specify a domain for both objects and then upon commit, the values in all versions of that record within that domain are updated.

You can specify a domain directly on an object, or specify it on the query when pulling objects out.

That does add some overheads to the object, and we will investigate having a common store behind all objects to reduce memory and allow the sharing of values. That said, it would make it impossible to get a copy of the object for the original values or any similar scenario.

If you set a defaultDomain on the SRKSettings object, then all objects work in this manner, but the ORM can slow considerably.

If you have any feedback for improvements to this system, or and compromises to the shared memory approach that you feel would be worthwhile to add then we would love to hear them.

Many thanks,
Adrian.

[ayoze]

Hello,

well, first of all, thanks for the fast reply!

The point of my question is because of RAM usage... let's say I have 2000 person in a query and I need to access its department property (to paint the department name, for example). In that case I will have 2000 Person objects + 2000 Department objects, right? The problem is not only when changing properties (the domain approach looks interesting, thanks) but also when querying. Any ideas on that?

Thanks

[editfmah]

Hi,

The Department object would only be loaded when referenced, but the problem is it is then held onto. What may be worth implementing is a call to "free all related objects", which would clear out the entities and put back the lazy loader objects instead.

But the initial 2000 object query will not have 2000 Department objects in it as well as with relationships spidering thorough entity structures things would soon get out of hand. Especially as a lookup by PK is generally very fast.

So we could maybe think about never retaining the Department object, but it would then query for every property that was touched.

I don't think there is a perfect way to solve all the issues for every angle, but we are happy to discuss your thoughts about how you would expect this to be solved or suggestions for modifying the interfaces.

As a general rule, SharkORM promotes the retrieval of objects as they are needed as opposed to holding onto them (not always appropriate we know), and huge datasets to drive visual objects such as tableviews etc... we implemented the batch parameter on queries. Which only holds in memory the records within the batch window size so the result set will report a full size but only ever contain a window of data.

Thanks.

[ayoze]

And why not an optional retain/not retain boolean? And ever more: why not a boolean to define a class or relationship being a singleton?

[editfmah]

Yes, we have something for that already. In the settings class we have a bool to forget all about lightwight property values, but i'm not quite sure if it does the same for related properties. But if it doesn't then it's a bug and it can be fixed easily enough.

Your suggestion of a proeprty to state if objects should be singleton for a particular class is interesting, but it might be best i fthat is done by domain instead. Therefore all objects that are members of a particular domain will be singletons.

There are some complications around the event model here which would need to be well thought through.

[editfmah]

Work on this has started for a release within the next couple of versions.

[ayoze]

Hello! Any advances on this? Do you need some help/collaboration?