Proxies, multiple copies of same object and #=

[jtuchel]

Hi there,

Sometimes. programming feels like snake & ladders. You're on field #183. #184 has a snake down to #4. You roll the dice and it shows 1. Back to basics.

I just had to redo a large part of an application where some "static" objects will not be held in a global any more, but will be mapped with normal 1:n and n:m relationships. This brought me back to a question I hadn't thought about any more in a while. And I wonder if what I am seeing is correct behaviour.

Some of the objects that are now mapped as part of the business model and referenced by OneToOneMappings and OneToManyMappings are referenced from a lot of places in the object model. This leads to the fact that I can have multiple proxies and even multiple instances of the same object in my Session. Like I have User Bob with ID 1 in a few collections and other places. Some of the references point to an instance of User with hash 253, some are still proxies, and some hold an instance of User with hash 845.

This has the interesting effect, at least in VAST, that if a Collection holds onto Bob's copy with hash 253, it won't answer #includes: with true if I ask with Bob's 845 copy. So it seems like Bob isn't Bob until you think of comparing the hashes.

Of course I can implement my #= on User and make sure that two Users are the same if the reference the same primary key. But I wonder if it is expected that the very same GlorpSession will allow two or more copies of an object in memory. I thought one of the main points of a Session's cache architecture is to make sure that the same Row read using the same mappings for the same class will end up as the same (technically: identical) object.

To put it short: I was expecting that inside a single Glorp Session, there is only and exactly one materialized working copy of Bob at any time. So each Bob is == to each other. But it is not the case here.

So questions:

• Is it okay that there are multiple copies of the same Bob in one GlorpSession?
  Is this only true in some Diealects?
  Or am I breaking it somewhere?
• Will it be okay to just override #= ? My #includes: case and many others will work, but I am thinking of troubles with Glorp commits.
• So is it advisible to override #= for all persistent objects, I guess?
  

Please note I am only talking about objects read from the database. I know I can always send User new and create many transient Bobs with the same ID. But that is not what I am talking about. I know I can't expect those to magically know they are only avatars of a record in the database...

I look forward to a discussion on this issue and hope to learn something new here.

Joachim

[Todd Blanchard]

Glorp uses an identity cache.

Within a session, there should be only one copy of fetched object Bob even if it can be reached through many different paths in your object graph.

The cache is there for correctness to prevent disjoint edits clobbering each other.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to glorp-group...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/66c2d129-c5b7-43f9-8068-fde6c80497fdn%40googlegroups.com.

[Joachim Tuchel]

Todd,

thanks for your comment. So what I am encountering is not normal and I have to look for the reasons of this wrong behavior. Good I askedm because, tbh, ensured identity is what I'd expect from a framework like Glorp. Seems we're doing something wrong and now I know for sure.

Joachim

Am 08.07.23 um 00:38 schrieb Todd Blanchard:

You received this message because you are subscribed to a topic in the Google Groups "glorp-group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/glorp-group/d9eMMvJlYp4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to glorp-group...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/2C1E3B0B-EE3F-45C5-870D-C02A7AD4F65F%40gmail.com.

-- 

----------------------------------------------------------------------- 
Objektfabrik Joachim Tuchel              mailto:jtu...@objektfabrik.de 
Fliederweg 1                                 http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0                    Fax: +49 7141 56 10 86 1

[Alan Knight]

Things I can think of

 - There are different types of caches,some with limited sizes. If a cache has reached its size limit and removed items, or if the cache was manually flushed, then the object was read again, you would get a different instance.

 - There can be different proxies to an object. Those proxies will not be identical. Glorp tries to compensate for this, e.g. Proxy>>= is something like ^self yourself = other yourself.

And I think there were some more limitations on what could be overridden in VA than in VW so some circumstances might be less transparent. But e.g. if a real object just has default equality as identity, and then you send realObject = proxy, it will be false.

But basically, while there are edge cases, identity should definitely be preserved.

I described the situation you are having as "reference data", where you have things that are referred to a lot and don't change. I think there were some facilities for handling that specially, e.g. not following references into a unit of work, so in normal use you don't have to compare the list of countries on every commit to see if any of them have changed. I don't remember exactly where, but if you look for that term you might find something. Or maybe it just something I thought about, but didn't implement.

To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/47c0f3e9-79e2-3e1a-8b92-d7303eab4ca3%40objektfabrik.de.

[jtuchel]

Alan,

thanks for your thoughts on this.

So I cannot fully rely on object identity if there are multiple proxies for the same object - for more than one possible reason. I must be prepared for situations where two materialized instances of the "same object" in the same session are not identical.

I couldn't find anything for "glorp reference data", but I know the dsicussion about "constant read-only" objects has been around several times. My solution to this is a class variable and a glorp converter that accesses the class variable. Not sure it is a clever one, and it has its drawbacks, but it seems to work "well enough" for most of my scenarios.

I need to think about this a little more.

Joachim