referencedColumnName mapping problem
rnentjes
It looks like Ebean doesn't support referencedColumnName in ManyToOne
relations. It seems to require that the referenced column is an
primary key column. Is this correct?
For example, is it possible to map the company object in a user object
by matching them on a companyName field i.o. on a primary key.
Something like this in the user bean (entity?):
@ManyToOne
@JoinColumn(name="CompanyName", referencedColumnName="Name")
private Company company
And this in company:
@Id
private int id;
@Column(name="Name") // note, not a primary key field
private String name;
When we try something like this we get the following exception:
Caused by: javax.persistence.PersistenceException: Error with the Join
on [com.bla.model.contract.sale.TblSaleSched.prodSpecifications].
Could not find the local match for [ProdSpecCode] Perhaps an error in
a @JoinColumn
at
com.avaje.ebeaninternal.server.deploy.BeanPropertyAssoc.createImportedScalar(BeanPropertyAssoc.java:
393)
at
com.avaje.ebeaninternal.server.deploy.BeanPropertyAssoc.createImportedId(BeanPropertyAssoc.java:
350)
at
com.avaje.ebeaninternal.server.deploy.BeanPropertyAssocOne.initialise(BeanPropertyAssocOne.java:
118)
at
com.avaje.ebeaninternal.server.deploy.BeanDescriptor.initialiseOther(BeanDescriptor.java:
650)
at
com.avaje.ebeaninternal.server.deploy.BeanDescriptorManager.initialiseAll(BeanDescriptorManager.java:
354)
at
com.avaje.ebeaninternal.server.deploy.BeanDescriptorManager.deploy(BeanDescriptorManager.java:
257)
at
com.avaje.ebeaninternal.server.core.InternalConfiguration.<init>(InternalConfiguration.java:
135)
at
com.avaje.ebeaninternal.server.core.DefaultServerFactory.createServer(DefaultServerFactory.java:
189)
at
com.avaje.ebeaninternal.server.core.DefaultServerFactory.createServer(DefaultServerFactory.java:
121)
at
com.avaje.ebeaninternal.server.core.DefaultServerFactory.createServer(DefaultServerFactory.java:
67)
at
com.avaje.ebean.EbeanServerFactory.create(EbeanServerFactory.java:63)
at com.avaje.ebean.Ebean
$ServerManager.getWithCreate(Ebean.java:236)
at com.avaje.ebean.Ebean$ServerManager.<init>(Ebean.java:192)
at com.avaje.ebean.Ebean$ServerManager.<init>(Ebean.java:158)
at com.avaje.ebean.Ebean.<clinit>(Ebean.java:152)
Rob Bygrave
> It seems to require that the referenced column is an primary key column. Is this correct?
What is the reason for trying to use company name rather than the primary key?
I'm guessing that you actually don't have foreign keys between these tables?
To unsubscribe from this group, send email to ebean+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
rnentjes
The reason for this is a legacy database, used by other applications
as well (we can't change it). There are hardly any foreign key
constraints and the implicit ones are not always on primary key. There
are also a lot of compound primary keys, complicating the matter.
Is there a rational for not supporting secondary key's? I would think
this is not an uncommon scenario.
Btw, I don't know what the JPA spec says about it, but the hibernate
implementation is fine with this mapping.
Actually this seems to be the only show stopper that prevents us from
moving to Ebean, after removing these mappings everything else still
seems to work fine.
Regards, Rien
On Mar 29, 11:33 pm, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> > It seems to require that the referenced column is an primary key column.
>
> Is this correct?
>
> Yes.
>
> What is the reason for trying to use company name rather than the primary
> key?
> I'm guessing that you actually don't have foreign keys between these tables?
>
Rob Bygrave
> Is there a rational for not supporting secondary key's?
Generally speaking I'd expect an RDBMS to more efficiently join against the real primary key (smaller, less mutable, more likely in memory) relative to using an secondary index (like company name - bigger, more mutable, less likely to be in memory). I don't see any benefits in joining to a 'non primary key column'.
I'd hope it is uncommon but as you say, the design has already been baked.
> after removing these mappings everything else still seems to work fine.
Cheers, Rob.
To unsubscribe from this group, send email to ebean+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Rob Bygrave
http://www.avaje.org/bugdetail-263.html
I have added the code into HEAD and tested it out a little and it seems to work ok. I have uploaded this as the 2.6.0-SNAPSHOT into the maven repository
... so, if you want to try it out and confirm that it works as expected that would be great.
The snapshot with this support added is:
http://www.avaje.org/archiva/repository/snapshots/org/avaje/ebean/2.6.0-SNAPSHOT/ebean-2.6.0-20100331.044526-1.jar
Cheers, Rob.
Rien
extended proof of concept and will let you know when there are any
problems.
Thank you for the quick fix!
On Mar 31, 6:52 am, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> I logged this as BUG 263 : Add support for joining to Non - PK columns
>
> http://www.avaje.org/bugdetail-263.html
>
> I have added the code into HEAD and tested it out a little and it seems to
> work ok. I have uploaded this as the 2.6.0-SNAPSHOT into the maven
> repository
>
> ... so, if you want to try it out and confirm that it works as expected that
> would be great.
>
> The snapshot with this support added is:http://www.avaje.org/archiva/repository/snapshots/org/avaje/ebean/2.6...
>
> Cheers, Rob.
>
> On Wed, Mar 31, 2010 at 9:43 AM, Rob Bygrave <robin.bygr...@gmail.com>wrote:
>
> > > The reason for this is a legacy database
>
> > Cool. I just wanted to double check.
>
> > > Is there a rational for not supporting secondary key's?
>
> > We could support it. As you say Ebean is just searching the Id properties
> > and instead it could search all the properties on the Ebean.
>
> > Generally speaking I'd expect an RDBMS to more efficiently join against the
> > real primary key (smaller, less mutable, more likely in memory) relative to
> > using an secondary index (like company name - bigger, more mutable, less
> > likely to be in memory). I don't see any benefits in joining to a 'non
> > primary key column'.
>
> > I'd hope it is uncommon but as you say, the design has already been baked.
>
> > > after removing these mappings everything else still seems to work fine.
>
> > Good to hear that.
>
> > Cheers, Rob.
>
