> Am 17.07.2018 um 19:12 schrieb Andrus Adamchik <[email protected]>: > >> 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
