4.1 templates with relationships

[Maik Musall <ma...@selbstdenker.ag>]

Hi,

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? One of my experimentation goals was to use Gson to serialize DOs from and to JSON, and the field-based approach would make that very simple, were it not for the relationships.

I also noticed that the template specifies the field scope as protected. Isn't that unnecessarily broad? My application works fine with those fields being private (which also makes the Gson case easier because I can just tell it to cover all private fields, automatically ignoring snapshotVersion, objectId, persistentState and other internal fields).

Maik

Re: 4.1 templates with relationships

[Maik Musall <ma...@selbstdenker.ag>]

> Am 18.07.2018 um 15:31 schrieb Andrus Adamchik <an...@objectstyle.org>:
>> 
>> On Jul 18, 2018, at 4:19 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>> 
>>> On Jul 18, 2018, at 4:04 PM, Maik Musall <ma...@selbstdenker.ag> wrote:
>>> 
>>>> 
>>>> 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 :)
>> 
>> I was asking as LinkRest provides essentially such framework / semantics. And it is far from trivial on the backend.
> 
> [Sorry didn't finish my thought... ]
> 
> Periodically someone would ask "how do I serialize Cayenne objects to JSON". Which to me means "is there a JSON serialization library without the complexity of LinkRest that produces readable JSON and allows to control serialization depth". But maybe I am overthinking it and typical use cases are simple and can be handled with ExclusionStrategy or a similar simple rule set.
> 
> If you can make GSON work, you should post an example somewhere. This seems like a popular question.

Will do.

In my case there is no REST interface. I'm producing a JSON that gets packaged along with other resources and then transferred over to a signage display (using rsync).

Maik

Re: 4.1 templates with relationships

[Andrus Adamchik <an...@objectstyle.org>]

> On Jul 18, 2018, at 4:19 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> 
> 
> 
>> On Jul 18, 2018, at 4:04 PM, Maik Musall <ma...@selbstdenker.ag> wrote:
>> 
>>> 
>>> 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 :)
> 
> I was asking as LinkRest provides essentially such framework / semantics. And it is far from trivial on the backend.

[Sorry didn't finish my thought... ]

Periodically someone would ask "how do I serialize Cayenne objects to JSON". Which to me means "is there a JSON serialization library without the complexity of LinkRest that produces readable JSON and allows to control serialization depth". But maybe I am overthinking it and typical use cases are simple and can be handled with ExclusionStrategy or a similar simple rule set.

If you can make GSON work, you should post an example somewhere. This seems like a popular question. 

Andrus

Re: 4.1 templates with relationships

[Andrus Adamchik <an...@objectstyle.org>]

> On Jul 18, 2018, at 4:04 PM, Maik Musall <ma...@selbstdenker.ag> wrote:
> 
>> 
>> 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 :)

I was asking as LinkRest provides essentially such framework / semantics. And it is far from trivial on the backend.

Andrus

Re: 4.1 templates with relationships

[Maik Musall <ma...@selbstdenker.ag>]

> Am 17.07.2018 um 19:12 schrieb Andrus Adamchik <an...@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

Re: 4.1 templates with relationships

[Andrus Adamchik <an...@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 :) 

> 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.

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?

Andrus


> On Jul 17, 2018, at 4:48 PM, Maik Musall <ma...@selbstdenker.ag> wrote:
> 
> Hi,
> 
> 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? One of my experimentation goals was to use Gson to serialize DOs from and to JSON, and the field-based approach would make that very simple, were it not for the relationships.
> 
> I also noticed that the template specifies the field scope as protected. Isn't that unnecessarily broad? My application works fine with those fields being private (which also makes the Gson case easier because I can just tell it to cover all private fields, automatically ignoring snapshotVersion, objectId, persistentState and other internal fields).
> 
> Maik
>