6:56 p.m.
Hi Folks, so I'm making some first baby steps toward implementing
support for Ceylon's collections in Hibernate by trying to make use of
the existing UserCollectionType stuff.
Of course this is surely the ideal way to handle this, but bear with
me for a sec because I would like to know why what I tried didn't
work.
So I wrote my SetUserType to implement UserCollectionType, and then I
wrote the following Ceylon attribute:
oneToMany { mappedBy="city"; }
collectionType { type="hib.SetUserType"; }
shared MutableSet<Person> people = HashSet<Person>();
Which is equivalent in the following Java:
@javax.persistence.OneToMany(mappedBy = "city")
@org.hibernate.annotations.CollectionType(type = "hib.SetUserType")
@com.redhat.ceylon.compiler.java.metadata.Ignore
private final ceylon.collection.MutableSet<Person> people;
But when I ran the code, I got this error:
Caused by: org.hibernate.AnnotationException: Illegal attempt to map a
non collection as a @OneToMany, @ManyToMany or @CollectionOfElements:
hib.City.people
at
org.hibernate.cfg.annotations.CollectionBinder.getCollectionBinder(CollectionBinder.java:322)
at
org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1874)
at
org.hibernate.cfg.AnnotationBinder.processIdPropertiesIfNotAlready(AnnotationBinder.java:904)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:731)
at
org.hibernate.boot.model.source.internal.annotations.AnnotationMetadataSourceProcessorImpl.processEntityHierarchies(AnnotationMetadataSourceProcessorImpl.java:245)
at
org.hibernate.boot.model.process.spi.MetadataBuildingProcess$1.processEntityHierarchies(MetadataBuildingProcess.java:222)
at
org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:265)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:770)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:797)
at
org.hibernate.jpa.HibernatePersistenceProvider.createEntityManagerFactory(HibernatePersistenceProvider.java:58)
... 32 more
Is @CollectionType supposed to work with @OneToMany?
Thanks,
Gavin
6:57 p.m.
On Sun, Nov 22, 2015 at 1:56 AM, Gavin King <gavin.king(a)gmail.com> wrote:
Of course this is surely the ideal way to handle this, but bear with
me for a sec because I would like to know why what I tried didn't
work.
I mean "surely *not* the ideal way".
--
Gavin King
gavin(a)ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org
12:57 a.m.
I think that only the Java Collection types work with the JPA @OneToMany
associations, as it's described int his issue:
https://hibernate.atlassian.net/browse/HHH-4417
So, even when specifying a @CollectionType, the return type must be a
List/Set:
@OneToMany(...)
@CollectionType( type="MyCustomListType" )public List getOrders()
Vlad
On Sun, Nov 22, 2015 at 2:57 AM, Gavin King <gavin.king(a)gmail.com> wrote:
On Sun, Nov 22, 2015 at 1:56 AM, Gavin King
<gavin.king(a)gmail.com> wrote:
> Of course this is surely the ideal way to handle this, but bear with
> me for a sec because I would like to know why what I tried didn't
> work.
I mean "surely *not* the ideal way".
--
Gavin King
gavin(a)ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:37 a.m.
Ah, OK, thanks for the link, Vlad, now I think I sorta maybe see why.
With XML-based mappings, the semantic "kind" of collection is explicit
(<list/> or <set/> or whatever) whereas with annotations that is
determined by looking at the property type. The UserCollectionType
doesn't actually have this information.
So then I guess I'm going to need a bit of a deeper hack to make this work.
On Sun, Nov 22, 2015 at 7:57 AM, Vlad Mihalcea <mihalcea.vlad(a)gmail.com> wrote:
I think that only the Java Collection types work with the JPA
@OneToMany
associations, as it's described int his issue:
https://hibernate.atlassian.net/browse/HHH-4417
So, even when specifying a @CollectionType, the return type must be a
List/Set:
@OneToMany(...)
@CollectionType( type="MyCustomListType" )
public List getOrders()
Vlad
On Sun, Nov 22, 2015 at 2:57 AM, Gavin King <gavin.king(a)gmail.com> wrote:
>
> On Sun, Nov 22, 2015 at 1:56 AM, Gavin King <gavin.king(a)gmail.com> wrote:
>
> > Of course this is surely the ideal way to handle this, but bear with
> > me for a sec because I would like to know why what I tried didn't
> > work.
>
> I mean "surely *not* the ideal way".
>
> --
> Gavin King
> gavin(a)ceylon-lang.org
> http://profiles.google.com/gavin.king
> http://ceylon-lang.org
> http://hibernate.org
> http://seamframework.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Gavin King
gavin(a)ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org
1:41 p.m.
The annotation binder code does this checking. Ultimately (unfortunately)
the binding code does need to understand whether to build a
o.h.mapping.Set, o.h.mapping.List, etc. It makes the reasonable assumption
that the custom collection type (ceylon.collection.MutableSet) at least
implements one of the standard Java collection framework interfaces. We
could certainly introduce a hint for cases like yours where that is not the
case (so long as you implement your own PersistentCollection as well that
should be enough). Something like:
@org.hibernate.annotations.CollectionType(type = "hib.SetUserType",
nature=PluralAttributeNature.SET)
where `CollectionType.nature` is the
org.hibernate.boot.model.source.spi.PluralAttributeNature
enum:
public enum PluralAttributeNature {
BAG( Collection.class, false ),
ID_BAG( Collection.class, false ),
SET( Set.class, false ),
LIST( List.class, true ),
ARRAY( Object[].class, true ),
MAP( Map.class, true );
...
}
On Sun, Nov 22, 2015 at 4:38 AM Gavin King <gavin.king(a)gmail.com> wrote:
Ah, OK, thanks for the link, Vlad, now I think I sorta maybe see
why.
With XML-based mappings, the semantic "kind" of collection is explicit
(<list/> or <set/> or whatever) whereas with annotations that is
determined by looking at the property type. The UserCollectionType
doesn't actually have this information.
So then I guess I'm going to need a bit of a deeper hack to make this work.
On Sun, Nov 22, 2015 at 7:57 AM, Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> I think that only the Java Collection types work with the JPA @OneToMany
> associations, as it's described int his issue:
>
> https://hibernate.atlassian.net/browse/HHH-4417
>
> So, even when specifying a @CollectionType, the return type must be a
> List/Set:
>
> @OneToMany(...)
> @CollectionType( type="MyCustomListType" )
> public List getOrders()
>
> Vlad
>
> On Sun, Nov 22, 2015 at 2:57 AM, Gavin King <gavin.king(a)gmail.com>
wrote:
>>
>> On Sun, Nov 22, 2015 at 1:56 AM, Gavin King <gavin.king(a)gmail.com>
wrote:
>>
>> > Of course this is surely the ideal way to handle this, but bear with
>> > me for a sec because I would like to know why what I tried didn't
>> > work.
>>
>> I mean "surely *not* the ideal way".
>>
>> --
>> Gavin King
>> gavin(a)ceylon-lang.org
>> http://profiles.google.com/gavin.king
>> http://ceylon-lang.org
>> http://hibernate.org
>> http://seamframework.org
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
--
Gavin King
gavin(a)ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3325
days inactive
3326
days old
4 comments
3 participants
participants (3)
-
Gavin King -
Steve Ebersole -
Vlad Mihalcea