cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maik Musall <m...@selbstdenker.ag>
Subject Re: 4.1 templates with relationships
Date Wed, 18 Jul 2018 13:04:54 GMT

> Am 17.07.2018 um 19:12 schrieb Andrus Adamchik <andrus@objectstyle.org>:
> 
>> I'm experimenting with 4.1 and field-based DataObjects. I noticed, using the standard
4.1 server superclass template, that the fields that cover relationships aren't narrowly typed
but are simply specified as Object, which is apparently necessary because they may get populated
with a ToOneFault or a ToManyFault. Is there really no way to get these types more specific?
> 
> I guess an alternative way is to create pairs of typed fields ("T related", "ToOneFault
relatedFault"). This will have memory overhead though. IIRC 8 bytes per object per relationship
on a 64-bit architecture, i.e. not that small, considering how may objects one might keep
in memory. So our performance improvement benchmarks vs 4.0 won't look as impressive :) 

Indeed. Not really an option for me in general. Pity.

>> I also noticed that the template specifies the field scope as protected. Isn't that
unnecessarily broad? 
> 
> I suspect since getters are doing extra work, it was decided to expose bare ivars to
allow subclasses to manipulate them directly. Having said that, there's always "readPropertyDirectly(..)"
and "writePropertyDirectly(..)" to access those fields in any special yet-unforeseen cases.
So I wouldn't mind if we make the ivars private in the future releases.

Did anyone manipulate the hashmaps directly with good reason before we had the field-based
implementation?

> BTW, with your Gson serialization, how do you deal with controlled serialization of essentially
infinite graphs? Do you provide a spec of how deep to go down the relationships path?

I don't have that problem in my experimentation project because I can use an ExclusionStrategy
there that solves it. If actual cyclic references need to be expressed, I guess that would
be a custom solution with semantics encoded in JSON that the consumer on the other end would
need to know about. But I'm not trying to serialize my entire database to someone :)

Maik
Mime
View raw message