Quantcast

Mapping Other Collection Types

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Mapping Other Collection Types

graemer
I want to open a discussion here about how we proceed to add support
for mapping collection types other than java.util.Set to GORM. In
Hibernate annotations the details are described here:

http://www.hibernate.org/hib_docs/annotations/reference/en/html_single/#d0e2123

For a List type we really need an index column? Do we allow the user
to specifiy the index column or generate one by convention?

The same case for support arrays of objects like Integer[] this
information is needed.. otherwise hibernate assumes its a bag which is
sub optimal the main downside being and I quote the hibernate doc:

"Bags are the worst case. Since a bag permits duplicate element values
and has no index column, no primary key may be defined. Hibernate has
no way of distinguishing between duplicate rows. Hibernate resolves
this problem by completely removing (in a single DELETE) and
recreating the collection whenever it changes. This might be very
inefficient."

Graeme
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

RE: Mapping Other Collection Types

Dierk König
Yes, when doing the tutor example, I first thought it would be great
to have a sequence-aware type like List.
However, this implies that you are using bi-directional relations and
the 'non-owning' side determines the type. What if there two non-owning
sides with different types?
I currently see no way to get around index columns in case a sequence
is needed. However, it would be cool if there could be some support
for operations on such an index attribute like moveTo(index), compress(),
and such.

cheers
Mittie

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]On Behalf
> Of Graeme Rocher
> Sent: Dienstag, 25. April 2006 13:09
> To: [hidden email]
> Subject: [grails-dev] Mapping Other Collection Types
>
>
> I want to open a discussion here about how we proceed to add support
> for mapping collection types other than java.util.Set to GORM. In
> Hibernate annotations the details are described here:
>
> http://www.hibernate.org/hib_docs/annotations/reference/en/html_si
ngle/#d0e2123

For a List type we really need an index column? Do we allow the user
to specifiy the index column or generate one by convention?

The same case for support arrays of objects like Integer[] this
information is needed.. otherwise hibernate assumes its a bag which is
sub optimal the main downside being and I quote the hibernate doc:

"Bags are the worst case. Since a bag permits duplicate element values
and has no index column, no primary key may be defined. Hibernate has
no way of distinguishing between duplicate rows. Hibernate resolves
this problem by completely removing (in a single DELETE) and
recreating the collection whenever it changes. This might be very
inefficient."

Graeme
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Mapping Other Collection Types

W. Eric Trull
In reply to this post by graemer
Graeme Rocher <graemerocher <at> yahoo.co.uk> writes:

>
> I want to open a discussion here about how we proceed to add support
> for mapping collection types other than java.util.Set to GORM. In
> Hibernate annotations the details are described here:
>
>
http://www.hibernate.org/hib_docs/annotations/reference/en/html_single/#d0e2123

>
> For a List type we really need an index column? Do we allow the user
> to specifiy the index column or generate one by convention?
>
> The same case for support arrays of objects like Integer[] this
> information is needed.. otherwise hibernate assumes its a bag which is
> sub optimal the main downside being and I quote the hibernate doc:
>
> "Bags are the worst case. Since a bag permits duplicate element values
> and has no index column, no primary key may be defined. Hibernate has
> no way of distinguishing between duplicate rows. Hibernate resolves
> this problem by completely removing (in a single DELETE) and
> recreating the collection whenever it changes. This might be very
> inefficient."
>
> Graeme
>
>

My current issue with List and array mapping is that you *have* to specify an
index column.  I have a (unidirectional) many-to-many relationship, in a link
table, that does not specify or need any ordering.  So a Set is fine except
the POJO then gets shipped to clients via a Web Service.  In order to maintain
web service interoperability (i.e. .NET), I cannot use a Set, List or any
other java.util collection, but must use an array of my associated objects.  
I'm happy with my order being the ordering that the associated rows are
returned by the select statement.  If Hibernate must have an ordering (to not
degrade to a Bag situation), then order them by the foreign key or allow me to
specify a column in the associated table to order by (e.g. date, natural
id, ?).

Thanks.

-Eric Trull





Loading...