words, words, words

[Dierk König]

Hiall,


On http://grails.codehaus.org/GORM it says:
"""
To define the owning side of one-to-one or
many-to-one relationship we use the "belongsTo" property.
"""

I think this is a bit misleading, since the 'owning' side
isn't the owner of this containment structure. It is more
the 'being owned' side (the book in this case) or in other
words 'the belonging' (if that's a valid word).

Ii could be remembered like so:
- an owner can have belongings
- belongings use the 'belongsTo' property to refer to their owner(s)
- if an owner dies, all his belongings vanish.

----

If the 'relationships' property tells that this object 'relates to many'
objects of the referred class, it may be more self-explaining to call
this property 'relatesToMany' (?)

class Author {
    @Property Long id
    @Property Long version

    @Property relatesToMany= ["books" : Book.class]

    @Property String name
    @Property Set books = new HashSet()
}

or not?

Just some thoughts
Mittie

[graemer]

On 28/02/06, Dierk Koenig <[hidden email]> wrote:

> Hiall,
>
>
> On http://grails.codehaus.org/GORM it says:
> """
> To define the owning side of one-to-one or
> many-to-one relationship we use the "belongsTo" property.
> """
>
> I think this is a bit misleading, since the 'owning' side
> isn't the owner of this containment structure. It is more
> the 'being owned' side (the book in this case) or in other
> words 'the belonging' (if that's a valid word).

Ah yes I got this logic a bit mixed up :-)

>
> Ii could be remembered like so:
> - an owner can have belongings
> - belongings use the 'belongsTo' property to refer to their owner(s)
> - if an owner dies, all his belongings vanish.

That sums it up perfectly

>
> ----
>
> If the 'relationships' property tells that this object 'relates to many'
> objects of the referred class, it may be more self-explaining to call
> this property 'relatesToMany' (?)

Yes I thought about doing this, but i wasnt sure if I should as the
fact that it is of type Set implicity means its a "many" if you know
what i mean, so having this is rather redundant.

But maybe just for consistency it should be as you say below? What do you think?

Graeme

>
> class Author {
>     @Property Long id
>     @Property Long version
>
>     @Property relatesToMany= ["books" : Book.class]
>
>     @Property String name
>     @Property Set books = new HashSet()
> }
>
> or not?
>
> Just some thoughts
> Mittie
>

[Dierk König]

> > If the 'relationships' property tells that this object 'relates to many'
> > objects of the referred class, it may be more self-explaining to call
> > this property 'relatesToMany' (?)
>
> Yes I thought about doing this, but i wasnt sure if I should as the
> fact that it is of type Set implicity means its a "many" if you know
> what i mean, so having this is rather redundant.

At least for me, it cannot be redundant enough ;-)
It's crazy but I alway struggle with such easy concepts as 'one' and
'many'. I may be kind of dyslexic to that (not for objects but for
relations). It get's even worse with UML
where I always think that the star is on the wrong side of the
association...

We have to give it a name anyway, then why not giving one that
reveals best what it's doing?
Since 'belongsTo' is already a verb phrase 'relatesToMany' or
'hasMany' or such would be analogous.

> But maybe just for consistency it should be as you say below?
> What do you think?

Yes, I think one of 'relatesToMany' or 'hasMany' would read
better.

Mittie

P.S. 'transients' is a bit of a different issue since it
denotes properties of the object itself, not relationships...

> > class Author {
> >     @Property Long id
> >     @Property Long version
> >
> >     @Property relatesToMany= ["books" : Book.class]
> >
> >     @Property String name
> >     @Property Set books = new HashSet()
> > }
> >
> > or not?
> >
> > Just some thoughts
> > Mittie
> >

[Dierk König]

> > It could be remembered like so:
> > - an owner can have belongings
> > - belongings use the 'belongsTo' property to refer to their owner(s)
> > - if an owner dies, all his belongings vanish.
>
> That sums it up perfectly
>

I added this to the docs (GORM) and the table of relationship
cardinalities and their handling in GORM.
Please revise. I may have gone wrong.

BTW: is -to-many always as Set or is List also supported (like
in Hibernate)?

cheers
Mittie

[graemer]

On 28/02/06, Dierk Koenig <[hidden email]> wrote:

> > > It could be remembered like so:
> > > - an owner can have belongings
> > > - belongings use the 'belongsTo' property to refer to their owner(s)
> > > - if an owner dies, all his belongings vanish.
> >
> > That sums it up perfectly
> >
>
> I added this to the docs (GORM) and the table of relationship
> cardinalities and their handling in GORM.
> Please revise. I may have gone wrong.

Great!

>
> BTW: is -to-many always as Set or is List also supported (like
> in Hibernate)?
At the moment Set is only supported and this makes sense for most
cases as persistent instances are unique (ie they represent a row in
the db)

Maybe one day we can support Lists to

Graeme

>
> cheers
> Mittie
>

[Dierk König]

> > BTW: is -to-many always as Set or is List also supported (like
> > in Hibernate)?
> At the moment Set is only supported and this makes sense for most
> cases as persistent instances are unique (ie they represent a row in
> the db)
>
> Maybe one day we can support Lists too

The advantage is sequence. E.g. for my TutorialEntry class, each
Entry has children and if that's a Set, I cannot rely on the
sequence but have to maintain my own 'position' property...
That's certainly very uncommon in relational thinking but
not so uncommon in object thinking :-)

good night
Mittie

[graemer]

On 28/02/06, Dierk Koenig <[hidden email]> wrote:

> > > BTW: is -to-many always as Set or is List also supported (like
> > > in Hibernate)?
> > At the moment Set is only supported and this makes sense for most
> > cases as persistent instances are unique (ie they represent a row in
> > the db)
> >
> > Maybe one day we can support Lists too
>
> The advantage is sequence. E.g. for my TutorialEntry class, each
> Entry has children and if that's a Set, I cannot rely on the
> sequence but have to maintain my own 'position' property...
> That's certainly very uncommon in relational thinking but
> not so uncommon in object thinking :-)

If you're worried about sequence just use SortedSet as the interface
and make your objects implement Comparable

Graeme
>
> good night
> Mittie
>