On 28/01/2010, at 2:45 PM, Lachlan Deck wrote:
> On 27/01/2010, at 2:03 AM, Andrus Adamchik wrote:
>
>> So do you have a stack trace of the error BTW?
>
> Yep - apologies for the delay. See below.
Woops, looks like this was from a NamedQuery.
> with regards,
> --
>
> Lachlan Deck
>
> ObjEnti
On 27/01/2010, at 2:03 AM, Andrus Adamchik wrote:
> On Jan 26, 2010, at 4:50 PM, Lachlan Deck wrote:
>
>> Strictly speaking, yes. But you could also say that one is a derivative of
>> the other. e.g., upper-casing camel casing and joined via underscore which
>> is a common db mapping (which per
On Jan 26, 2010, at 5:37 PM, Lachlan Deck wrote:
Does this affect sql templates as well from ROP?
Not this particular issue. So it depends on how SQLTemplate metadata
handling is implemented (and IIRC it is implemented in an ROP-safe way).
Andrus
On 27/01/2010, at 2:25 AM, Andrus Adamchik wrote:
> Actually looks like we can reproduce this problem. EJBQLQuery does query
> compilation on the client, and that accesses DbRelationships. So this is not
> related to naming, but rather to the use of joins.
>
> A fix can be rather invasive, so h
Actually looks like we can reproduce this problem. EJBQLQuery does
query compilation on the client, and that accesses DbRelationships. So
this is not related to naming, but rather to the use of joins.
A fix can be rather invasive, so how does everybody feel about making
EJBQL a server-only
On Jan 26, 2010, at 4:50 PM, Lachlan Deck wrote:
Strictly speaking, yes. But you could also say that one is a
derivative of the other. e.g., upper-casing camel casing and joined
via underscore which is a common db mapping (which perhaps cayenne
allows for, especially when reverse engineeri
On 27/01/2010, at 12:52 AM, Khailenko Ksenia wrote:
> Does the scenario at
> org.apache.cayenne.CayenneContextEJBQLTest.testEJBQLSelect() satisfy to the
> conditions you are talking about?
> Because in such a case we have the DbEntity with name "MT_TABLE1" and the
> ObjEntity with name "MtTable1"
Does the scenario at
org.apache.cayenne.CayenneContextEJBQLTest.testEJBQLSelect() satisfy to the
conditions you are talking about?
Because in such a case we have the DbEntity with name "MT_TABLE1" and the
ObjEntity with name "MtTable1" - they are different, aren't they? This test
successfully passe
On 26/01/2010, at 6:51 PM, Andrus Adamchik wrote:
> Will need to investigate that. Could be a bug. IIRC we officially supported
> EJBQL on the client.
Sure. Just to be clear, this error only occurs if the DbEntity name differs
from the ObjEntity name. Similar problems would occur (I imagine) wi
Will need to investigate that. Could be a bug. IIRC we officially
supported EJBQL on the client.
Andrus
On Jan 26, 2010, at 2:10 AM, Lachlan Deck wrote:
On 25/01/2010, at 6:19 PM, Andrus Adamchik wrote:
I realise that the original reasoning for this was security
This and also a general d
On 25/01/2010, at 6:19 PM, Andrus Adamchik wrote:
>> I realise that the original reasoning for this was security
>
> This and also a general desire to encapsulate as many server details as
> possible.
>
>> this presents a challenge for utilising EJBQ
>
> EJBQL should work without knowledge of
I realise that the original reasoning for this was security
This and also a general desire to encapsulate as many server details
as possible.
this presents a challenge for utilising EJBQ
EJBQL should work without knowledge of DbEntity. What errors are you
getting? We may be able to fix
Hi there,
ObjEntity.getDbEntityName() in ROP returns null as does DbEntity. I realise
that the original reasoning for this was security but this presents a challenge
for utilising EJBQL (or SQLTemplate for that matter) to some extent from ROP.
Two immediate problems:
- if the ROP code only know
13 matches
Mail list logo
