You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Marcin Skladaniec <ma...@ish.com.au> on 2007/06/05 07:33:42 UTC

SQLTemplate not faulting an object

Hi everyone

I'm having some troubles with SQLTemplate. The one I use is fairly  
simple:

SQLTemplate query = new SQLTemplate(Student.class, "select * from  
Student WHERE isDeleted = 1");

the student entity is defined by :

	<db-entity name="Student">
		<db-attribute name="studentNumber" type="BIGINT"/>
... some other fields here ...
		<db-attribute name="id" type="INTEGER" isPrimaryKey="true"  
isMandatory="true"/>
	</db-entity>

	<obj-entity name="Student"  
className="ish.oncourse.server.cayenne.Student"  
dbEntityName="Student"  
superClassName="ish.oncourse.server.cayenne.glue.CayenneDataObject" >
		<qualifier><![CDATA[(isDeleted = null) or (isDeleted = 0)]]></ 
qualifier>
		<obj-attribute name="studentNumber" type="java.lang.Long" db- 
attribute-path="studentNumber"/>
... some other fields here ...
		<obj-attribute name="id" type="java.lang.Integer" db-attribute- 
path="id"/>
	</obj-entity>

When the query is performed an exception is raised:

  [java] org.apache.cayenne.CayenneRuntimeException: [v.$ 
{project.version} ${project.build.date} ${project.build.time}] Null  
value for 'id'. Snapshot: org.apache.cayenne.DataRow@b549af[values= 
{STUDENTNUMBER=5, (Other fields in here, all in upper case), ID=241},  
version=-9223372036854775761, replaces=-9223372036854775808]. Prefix:  
null
[java]     at org.apache.cayenne.access.ObjectResolver.createObjectId 
(ObjectResolver.java:280)
      [java]     at  
org.apache.cayenne.access.ObjectResolver.objectFromDataRow 
(ObjectResolver.java:206)
      [java]     at  
org.apache.cayenne.access.ObjectResolver.objectsFromDataRows 
(ObjectResolver.java:120)
      [java]     at  
org.apache.cayenne.access.ObjectResolver.synchronizedObjectsFromDataRows 
(ObjectResolver.java:100)
      [java]     at  
org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConversio 
n(DataDomainQueryAction.java:433)
      [java]     at  
org.apache.cayenne.access.DataDomainQueryAction.execute 
(DataDomainQueryAction.java:124)
      [java]     at org.apache.cayenne.access.DataDomain.onQuery 
(DataDomain.java:722)
      [java]     at  
org.apache.cayenne.intercept.DataChannelCallbackInterceptor.onQuery 
(DataChannelCallbackInterceptor.java:74)
      [java]     at  
org.apache.cayenne.util.ObjectContextQueryAction.runQuery 
(ObjectContextQueryAction.java:282)
      [java]     at  
org.apache.cayenne.access.DataContextQueryAction.execute 
(DataContextQueryAction.java:59)
      [java]     at org.apache.cayenne.access.DataContext.onQuery 
(DataContext.java:1321)
      [java]     at org.apache.cayenne.access.DataContext.performQuery 
(DataContext.java:1310)
      [java]     at  
org.apache.cayenne.intercept.ObjectContextDecorator.performQuery 
(ObjectContextDecorator.java:98)
      [java]     at  
ish.oncourse.server.services.DataPopulationService.runService 
(DataPopulationService.java:688)
      [java]     at ish.oncourse.server.services.Service.run 
(Service.java:174)
      [java]     at java.lang.Thread.run(Thread.java:613)

What is wrong ? Why when all my field properties are set to lowercase  
(like "id") the SQLTemplate returns a DataRow with only capital  
letters ?


I have to use the SQLTemplate since my model defines a qualifier  
"<qualifier><![CDATA[(isDeleted = null) or (isDeleted = 0)]]></ 
qualifier>" and I actually want to fetch the records with  
isDeleted=1. I tried different ways to waive the constraint on the  
data like:

ObjEntity studentEntity = new ObjEntity 
("ish.oncourse.server.cayenne.Student");
Expression exp = studentEntity.getDeclaredQualifier();
studentEntity.setDeclaredQualifier(null);
SelectQuery selectQuery = new SelectQuery(studentEntity);
studentEntity.setDeclaredQualifier(exp);

but nothing worked. Did someone achieve it ?

Thanks
Marcin
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001





Re: SQLTemplate not faulting an object

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 5, 2007, at 7:36 PM, Bryan Lewis wrote:

> However, they wouldn't be a cure-all.

I guess it should work cross DB, as it will convert the result to the  
case mapped in Cayenne model (regardless of the DB default).

> I'd still need an occasional database check in my SQLTemplate-building
> code for other differences like 'limit' versus 'rownum'.

You probably know that already, but just in case I wanted to point  
out that the same SQLTemplate instance can hold syntax for multiple  
dialects, so you can generate the syntax for ALL db's you plan to  
support, and let Cayenne to pick the right one at runtime.

Andrus


Re: SQLTemplate not faulting an object

Posted by Bryan Lewis <br...@maine.rr.com>.
The case-setting methods sound like a fairly good idea.  We're currently
running on Oracle but preparing to convert to Postgres.  I sometimes
have to adjust the case of the column names in SQLTemplate sql, so those
methods might help with that.  However, they wouldn't be a cure-all. 
I'd still need an occasional database check in my SQLTemplate-building
code for other differences like 'limit' versus 'rownum'.  It doesn't
bother me to deal with such things in the few places where I've decided
to drop down to raw SQL.


Andrus Adamchik wrote:
> Yeah, capitalization mismatch between the default DB behavior and your
> mapping can bite you when you use "select *". You may have to use the
> "#result" directive to describe all your columns:
>
>    http://cayenne.apache.org/doc/scripting-sqltemplate.html
>
>
> Since this is a pretty common and annoying problem (and presuming that
> most users do follow some naming convention in mapping their
> case-insensitive DB), I wonder if we should add a simple fix - two
> methods in a SQLTemplate - "setUppercaseColumnNames",
> "setLowercaseColumnNames"? Anybody has thoughts on that? Or is there
> some JDBC way to achieve the same with "SELECT *" queries?
>
> Andrus
>
> On Jun 5, 2007, at 8:33 AM, Marcin Skladaniec wrote:
>
>> Hi everyone
>>
>> I'm having some troubles with SQLTemplate. The one I use is fairly
>> simple:
>>
>> SQLTemplate query = new SQLTemplate(Student.class, "select * from
>> Student WHERE isDeleted = 1");
>>
>> the student entity is defined by :
>>
>>     <db-entity name="Student">
>>         <db-attribute name="studentNumber" type="BIGINT"/>
>> ... some other fields here ...
>>         <db-attribute name="id" type="INTEGER" isPrimaryKey="true"
>> isMandatory="true"/>
>>     </db-entity>
>>
>>     <obj-entity name="Student"
>> className="ish.oncourse.server.cayenne.Student"
>> dbEntityName="Student"
>> superClassName="ish.oncourse.server.cayenne.glue.CayenneDataObject" >
>>         <qualifier><![CDATA[(isDeleted = null) or (isDeleted =
>> 0)]]></qualifier>
>>         <obj-attribute name="studentNumber" type="java.lang.Long"
>> db-attribute-path="studentNumber"/>
>> ... some other fields here ...
>>         <obj-attribute name="id" type="java.lang.Integer"
>> db-attribute-path="id"/>
>>     </obj-entity>
>>
>> When the query is performed an exception is raised:
>>
>>  [java] org.apache.cayenne.CayenneRuntimeException:
>> [v.${project.version} ${project.build.date} ${project.build.time}]
>> Null value for 'id'. Snapshot:
>> org.apache.cayenne.DataRow@b549af[values={STUDENTNUMBER=5, (Other
>> fields in here, all in upper case), ID=241},
>> version=-9223372036854775761, replaces=-9223372036854775808]. Prefix:
>> null
>> [java]     at
>> org.apache.cayenne.access.ObjectResolver.createObjectId(ObjectResolver.java:280)
>>
>>      [java]     at
>> org.apache.cayenne.access.ObjectResolver.objectFromDataRow(ObjectResolver.java:206)
>>
>>      [java]     at
>> org.apache.cayenne.access.ObjectResolver.objectsFromDataRows(ObjectResolver.java:120)
>>
>>      [java]     at
>> org.apache.cayenne.access.ObjectResolver.synchronizedObjectsFromDataRows(ObjectResolver.java:100)
>>
>>      [java]     at
>> org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConversion(DataDomainQueryAction.java:433)
>>
>>      [java]     at
>> org.apache.cayenne.access.DataDomainQueryAction.execute(DataDomainQueryAction.java:124)
>>
>>      [java]     at
>> org.apache.cayenne.access.DataDomain.onQuery(DataDomain.java:722)
>>      [java]     at
>> org.apache.cayenne.intercept.DataChannelCallbackInterceptor.onQuery(DataChannelCallbackInterceptor.java:74)
>>
>>      [java]     at
>> org.apache.cayenne.util.ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:282)
>>
>>      [java]     at
>> org.apache.cayenne.access.DataContextQueryAction.execute(DataContextQueryAction.java:59)
>>
>>      [java]     at
>> org.apache.cayenne.access.DataContext.onQuery(DataContext.java:1321)
>>      [java]     at
>> org.apache.cayenne.access.DataContext.performQuery(DataContext.java:1310)
>>
>>      [java]     at
>> org.apache.cayenne.intercept.ObjectContextDecorator.performQuery(ObjectContextDecorator.java:98)
>>
>>      [java]     at
>> ish.oncourse.server.services.DataPopulationService.runService(DataPopulationService.java:688)
>>
>>      [java]     at
>> ish.oncourse.server.services.Service.run(Service.java:174)
>>      [java]     at java.lang.Thread.run(Thread.java:613)
>>
>> What is wrong ? Why when all my field properties are set to lowercase
>> (like "id") the SQLTemplate returns a DataRow with only capital
>> letters ?
>>
>>
>> I have to use the SQLTemplate since my model defines a qualifier
>> "<qualifier><![CDATA[(isDeleted = null) or (isDeleted =
>> 0)]]></qualifier>" and I actually want to fetch the records with
>> isDeleted=1. I tried different ways to waive the constraint on the
>> data like:
>>
>> ObjEntity studentEntity = new
>> ObjEntity("ish.oncourse.server.cayenne.Student");
>> Expression exp = studentEntity.getDeclaredQualifier();
>> studentEntity.setDeclaredQualifier(null);
>> SelectQuery selectQuery = new SelectQuery(studentEntity);
>> studentEntity.setDeclaredQualifier(exp);
>>
>> but nothing worked. Did someone achieve it ?
>>
>> Thanks
>> Marcin
>> -------------------------->
>> ish
>> http://www.ish.com.au
>> Level 1, 30 Wilson Street Newtown 2042 Australia
>> phone +61 2 9550 5001   fax +61 2 9550 4001
>>
>>
>>
>>
>>
>


Re: Self-join

Posted by Andrus Adamchik <an...@objectstyle.org>.
Or actually ... I take it back :-)

The underlying cause is still the inability to build correct joins  
when traversing a multi-step path qualifier, such as "parent.parent =  
null". This explains why Mike's patch made a difference.

Andrus


On Jun 27, 2007, at 4:50 PM, Andrus Adamchik wrote:

> Just to clarify, CAY-732 is a real bug, but it is not a bug with  
> relationships to same entity per se (those resolve just fine). This  
> is a bug specifically related to *prefetching* on such relationships.
>
> Andrus
>
>
> On Jun 12, 2007, at 10:33 PM, Mike Kienenberger wrote:
>
>> Not really sure as I don't use them, but at least one issue with
>> self-joins is solved if you use my outer join patch for 1.2.
>>
>> https://issues.apache.org/cayenne/browse/CAY-732
>>
>>
>>
>> On 6/12/07, Fredrik Liden <fl...@translate.com> wrote:
>>> What is the status of self joins in v. 1.2.3?
>>> From the 2 posts I find in the archive seems like some people are  
>>> using
>>> it.
>>> The documentation doesn't mention it.
>>> Just wondering if it's ok to use or if there are any limitations  
>>> that
>>> discourages it's use?
>>>
>>> I'm have a set of nodes. I'm guessing the source node will have
>>> Source_node_id NULL or 0. And then the target nodes will refer  
>>> back to
>>> the source nodes Node_id. Would it be worth using self joins here or
>>> should I just look up the target nodes based on the source nodes  
>>> using
>>> regular queries and not worry about the relations?
>>>
>>> NODE
>>>
>>> Node_id (pk)
>>> Text
>>> Source_node_id (fk)
>>>
>>> Thanks!
>>> Fredrik
>>>
>>
>
>


Re: Self-join

Posted by Andrus Adamchik <an...@objectstyle.org>.
Just to clarify, CAY-732 is a real bug, but it is not a bug with  
relationships to same entity per se (those resolve just fine). This  
is a bug specifically related to *prefetching* on such relationships.

Andrus


On Jun 12, 2007, at 10:33 PM, Mike Kienenberger wrote:

> Not really sure as I don't use them, but at least one issue with
> self-joins is solved if you use my outer join patch for 1.2.
>
> https://issues.apache.org/cayenne/browse/CAY-732
>
>
>
> On 6/12/07, Fredrik Liden <fl...@translate.com> wrote:
>> What is the status of self joins in v. 1.2.3?
>> From the 2 posts I find in the archive seems like some people are  
>> using
>> it.
>> The documentation doesn't mention it.
>> Just wondering if it's ok to use or if there are any limitations that
>> discourages it's use?
>>
>> I'm have a set of nodes. I'm guessing the source node will have
>> Source_node_id NULL or 0. And then the target nodes will refer  
>> back to
>> the source nodes Node_id. Would it be worth using self joins here or
>> should I just look up the target nodes based on the source nodes  
>> using
>> regular queries and not worry about the relations?
>>
>> NODE
>>
>> Node_id (pk)
>> Text
>> Source_node_id (fk)
>>
>> Thanks!
>> Fredrik
>>
>


AW: Unit testing web apps

Posted by Peter Schröder <Pe...@freenet-ag.de>.
yes, there is a firefox plugin http://www.openqa.org/selenium-ide/ 

-----Ursprüngliche Nachricht-----
Von: Mike Kienenberger [mailto:mkienenb@gmail.com] 
Gesendet: Donnerstag, 14. Juni 2007 16:57
An: user@cayenne.apache.org
Betreff: Re: Unit testing web apps

Actually, I seem to recall that there are some Firefox (or maybe it
was IE) tools for developing Selenium tests rather rapidly.   I don't
remember the details as I was just casually investigating the tool at
the time.

On 6/14/07, Malcolm Edgar <ma...@gmail.com> wrote:
> The decision to develop UI unit tests really comes down to how much
> budget you have for your applications development.
>
> If you do, than that is great.  You can also develop some load testing
> capability at the same time. Just note is time consuming / expensive
> to do so.
>
> regards Malcolm Edgar
>
> On 6/14/07, Peter Schröder <Pe...@freenet-ag.de> wrote:
> > hi kevin,
> >
> > i think that testing the ui is a very important part for a good quality web-application. it also helps understanding the webapp for new developers or reminding you of things that have been implemented in a sloppy way. it is poor that in most cases i dont take the time to write some tests on that...
> >
> > kind regards
> > peter
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Kevin Menard [mailto:kmenard@servprise.com]
> > Gesendet: Mittwoch, 13. Juni 2007 20:34
> > An: user@cayenne.apache.org
> > Betreff: RE: Unit testing web apps
> >
> > > -----Original Message-----
> > > From: Malcolm Edgar [mailto:malcolm.edgar@gmail.com]
> > > Sent: Tuesday, June 12, 2007 9:47 PM
> > > To: user@cayenne.apache.org
> > > Subject: Re: Unit testing web apps
> > >
> > > I think writing unit tests for DAO/Service classes is OK, but
> > > going up to the UI tier is not worth the effort. This is due
> > > to the amount of change you see in UI's and the effort it
> > > takes to write and maintain these tests.
> >
> > I have to disagree here.  While they are a pain in the neck to maintain,
> > our selenium tests have turned up numerous problems.  Just recently we
> > discovered a problem with using a shared data cache on certain objects.
> > It also helps tests session-bound contexts.
> >
> > Since Selenium uses an XPath-like syntax for DOM navigation, you can
> > write tests that generally work even after UI changes.
> >
> > --
> > Kevin
> >
>

Re: Unit testing web apps

Posted by Mike Kienenberger <mk...@gmail.com>.
Actually, I seem to recall that there are some Firefox (or maybe it
was IE) tools for developing Selenium tests rather rapidly.   I don't
remember the details as I was just casually investigating the tool at
the time.

On 6/14/07, Malcolm Edgar <ma...@gmail.com> wrote:
> The decision to develop UI unit tests really comes down to how much
> budget you have for your applications development.
>
> If you do, than that is great.  You can also develop some load testing
> capability at the same time. Just note is time consuming / expensive
> to do so.
>
> regards Malcolm Edgar
>
> On 6/14/07, Peter Schröder <Pe...@freenet-ag.de> wrote:
> > hi kevin,
> >
> > i think that testing the ui is a very important part for a good quality web-application. it also helps understanding the webapp for new developers or reminding you of things that have been implemented in a sloppy way. it is poor that in most cases i dont take the time to write some tests on that...
> >
> > kind regards
> > peter
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Kevin Menard [mailto:kmenard@servprise.com]
> > Gesendet: Mittwoch, 13. Juni 2007 20:34
> > An: user@cayenne.apache.org
> > Betreff: RE: Unit testing web apps
> >
> > > -----Original Message-----
> > > From: Malcolm Edgar [mailto:malcolm.edgar@gmail.com]
> > > Sent: Tuesday, June 12, 2007 9:47 PM
> > > To: user@cayenne.apache.org
> > > Subject: Re: Unit testing web apps
> > >
> > > I think writing unit tests for DAO/Service classes is OK, but
> > > going up to the UI tier is not worth the effort. This is due
> > > to the amount of change you see in UI's and the effort it
> > > takes to write and maintain these tests.
> >
> > I have to disagree here.  While they are a pain in the neck to maintain,
> > our selenium tests have turned up numerous problems.  Just recently we
> > discovered a problem with using a shared data cache on certain objects.
> > It also helps tests session-bound contexts.
> >
> > Since Selenium uses an XPath-like syntax for DOM navigation, you can
> > write tests that generally work even after UI changes.
> >
> > --
> > Kevin
> >
>

Re: Unit testing web apps

Posted by Malcolm Edgar <ma...@gmail.com>.
The decision to develop UI unit tests really comes down to how much
budget you have for your applications development.

If you do, than that is great.  You can also develop some load testing
capability at the same time. Just note is time consuming / expensive
to do so.

regards Malcolm Edgar

On 6/14/07, Peter Schröder <Pe...@freenet-ag.de> wrote:
> hi kevin,
>
> i think that testing the ui is a very important part for a good quality web-application. it also helps understanding the webapp for new developers or reminding you of things that have been implemented in a sloppy way. it is poor that in most cases i dont take the time to write some tests on that...
>
> kind regards
> peter
>
> -----Ursprüngliche Nachricht-----
> Von: Kevin Menard [mailto:kmenard@servprise.com]
> Gesendet: Mittwoch, 13. Juni 2007 20:34
> An: user@cayenne.apache.org
> Betreff: RE: Unit testing web apps
>
> > -----Original Message-----
> > From: Malcolm Edgar [mailto:malcolm.edgar@gmail.com]
> > Sent: Tuesday, June 12, 2007 9:47 PM
> > To: user@cayenne.apache.org
> > Subject: Re: Unit testing web apps
> >
> > I think writing unit tests for DAO/Service classes is OK, but
> > going up to the UI tier is not worth the effort. This is due
> > to the amount of change you see in UI's and the effort it
> > takes to write and maintain these tests.
>
> I have to disagree here.  While they are a pain in the neck to maintain,
> our selenium tests have turned up numerous problems.  Just recently we
> discovered a problem with using a shared data cache on certain objects.
> It also helps tests session-bound contexts.
>
> Since Selenium uses an XPath-like syntax for DOM navigation, you can
> write tests that generally work even after UI changes.
>
> --
> Kevin
>

AW: Unit testing web apps

Posted by Peter Schröder <Pe...@freenet-ag.de>.
hi kevin,

i think that testing the ui is a very important part for a good quality web-application. it also helps understanding the webapp for new developers or reminding you of things that have been implemented in a sloppy way. it is poor that in most cases i dont take the time to write some tests on that...

kind regards
peter 

-----Ursprüngliche Nachricht-----
Von: Kevin Menard [mailto:kmenard@servprise.com] 
Gesendet: Mittwoch, 13. Juni 2007 20:34
An: user@cayenne.apache.org
Betreff: RE: Unit testing web apps

> -----Original Message-----
> From: Malcolm Edgar [mailto:malcolm.edgar@gmail.com] 
> Sent: Tuesday, June 12, 2007 9:47 PM
> To: user@cayenne.apache.org
> Subject: Re: Unit testing web apps
> 
> I think writing unit tests for DAO/Service classes is OK, but 
> going up to the UI tier is not worth the effort. This is due 
> to the amount of change you see in UI's and the effort it 
> takes to write and maintain these tests.

I have to disagree here.  While they are a pain in the neck to maintain,
our selenium tests have turned up numerous problems.  Just recently we
discovered a problem with using a shared data cache on certain objects.
It also helps tests session-bound contexts.

Since Selenium uses an XPath-like syntax for DOM navigation, you can
write tests that generally work even after UI changes.

-- 
Kevin

RE: Unit testing web apps

Posted by Kevin Menard <km...@servprise.com>.
> -----Original Message-----
> From: Malcolm Edgar [mailto:malcolm.edgar@gmail.com] 
> Sent: Tuesday, June 12, 2007 9:47 PM
> To: user@cayenne.apache.org
> Subject: Re: Unit testing web apps
> 
> I think writing unit tests for DAO/Service classes is OK, but 
> going up to the UI tier is not worth the effort. This is due 
> to the amount of change you see in UI's and the effort it 
> takes to write and maintain these tests.

I have to disagree here.  While they are a pain in the neck to maintain,
our selenium tests have turned up numerous problems.  Just recently we
discovered a problem with using a shared data cache on certain objects.
It also helps tests session-bound contexts.

Since Selenium uses an XPath-like syntax for DOM navigation, you can
write tests that generally work even after UI changes.

-- 
Kevin

Re: Unit testing web apps

Posted by Malcolm Edgar <ma...@gmail.com>.
I think writing unit tests for DAO/Service classes is OK, but going up
to the UI tier is not worth the effort. This is due to the amount of
change you see in UI's and the effort it takes to write and maintain
these tests.

regards Malcolm Edgar

On 6/13/07, Fredrik Liden <fl...@translate.com> wrote:
> Do you have any recommendations/guide lines for testing a Cayenne web
> application. Do I need a combination of cactus for the web pages and
> jUnit for the service layer and data objects? Would I be able to access
> the cayenne data context from within the setup and tear down functions.
> Or should I consider this testing as a completely separate application
> from the current web app since the test is not running as a servlet and
> can't get the context from there? How do you guys test your apps?
>
> Thanks!
> Fredrik
>

Re: Unit testing web apps

Posted by Mike Kienenberger <mk...@gmail.com>.
Selenium is what the Apache MyFaces project uses.

On 6/13/07, Fredrik Liden <fl...@translate.com> wrote:
> Thanks both,
>
> Yeah I'm guessing the UI layer is not as important as long as the service classes doesn't crumble if there's some UI bugs. Selenium looks quite interesting though. Peter, if I test the classes as plain java classes I'm guessing I would have to use
>
> DataContext context = DataContext.createDataContext();
> DataContext.bindThreadDataContext(context);
>
> Fredrik
>
>
> -----Original Message-----
> From: Peter Schröder [mailto:Peter.Schroeder@freenet-ag.de]
> Sent: Wednesday, June 13, 2007 12:35 AM
> To: user@cayenne.apache.org
> Subject: AW: Unit testing web apps
>
> hi fredrik,
>
> we use simple junit tests for testing the service layer of our webapps. in the service layer we receive a datacontext via the cayenne servlet-listener using DataContext.getThreadedDataContext(). so we do a DataContext.bindThreadedDataContext(newContext) in the setup-method of the unit-test.
>
> for testing the webapp there are several possibilites: html-unit, selenium ...
>
> kind regards
> peter
>
> -----Ursprüngliche Nachricht-----
> Von: Fredrik Liden [mailto:fliden@translate.com]
> Gesendet: Mittwoch, 13. Juni 2007 02:47
> An: user@cayenne.apache.org
> Betreff: Unit testing web apps
>
> Do you have any recommendations/guide lines for testing a Cayenne web
> application. Do I need a combination of cactus for the web pages and
> jUnit for the service layer and data objects? Would I be able to access
> the cayenne data context from within the setup and tear down functions.
> Or should I consider this testing as a completely separate application
> from the current web app since the test is not running as a servlet and
> can't get the context from there? How do you guys test your apps?
>
> Thanks!
> Fredrik
>

RE: Unit testing web apps

Posted by Fredrik Liden <fl...@translate.com>.
Thanks both,

Yeah I'm guessing the UI layer is not as important as long as the service classes doesn't crumble if there's some UI bugs. Selenium looks quite interesting though. Peter, if I test the classes as plain java classes I'm guessing I would have to use 

DataContext context = DataContext.createDataContext();
DataContext.bindThreadDataContext(context); 

Fredrik


-----Original Message-----
From: Peter Schröder [mailto:Peter.Schroeder@freenet-ag.de] 
Sent: Wednesday, June 13, 2007 12:35 AM
To: user@cayenne.apache.org
Subject: AW: Unit testing web apps

hi fredrik,

we use simple junit tests for testing the service layer of our webapps. in the service layer we receive a datacontext via the cayenne servlet-listener using DataContext.getThreadedDataContext(). so we do a DataContext.bindThreadedDataContext(newContext) in the setup-method of the unit-test.

for testing the webapp there are several possibilites: html-unit, selenium ...

kind regards
peter

-----Ursprüngliche Nachricht-----
Von: Fredrik Liden [mailto:fliden@translate.com] 
Gesendet: Mittwoch, 13. Juni 2007 02:47
An: user@cayenne.apache.org
Betreff: Unit testing web apps

Do you have any recommendations/guide lines for testing a Cayenne web
application. Do I need a combination of cactus for the web pages and
jUnit for the service layer and data objects? Would I be able to access
the cayenne data context from within the setup and tear down functions.
Or should I consider this testing as a completely separate application
from the current web app since the test is not running as a servlet and
can't get the context from there? How do you guys test your apps? 

Thanks!
Fredrik

AW: Unit testing web apps

Posted by Peter Schröder <Pe...@freenet-ag.de>.
hi fredrik,

we use simple junit tests for testing the service layer of our webapps. in the service layer we receive a datacontext via the cayenne servlet-listener using DataContext.getThreadedDataContext(). so we do a DataContext.bindThreadedDataContext(newContext) in the setup-method of the unit-test.

for testing the webapp there are several possibilites: html-unit, selenium ...

kind regards
peter

-----Ursprüngliche Nachricht-----
Von: Fredrik Liden [mailto:fliden@translate.com] 
Gesendet: Mittwoch, 13. Juni 2007 02:47
An: user@cayenne.apache.org
Betreff: Unit testing web apps

Do you have any recommendations/guide lines for testing a Cayenne web
application. Do I need a combination of cactus for the web pages and
jUnit for the service layer and data objects? Would I be able to access
the cayenne data context from within the setup and tear down functions.
Or should I consider this testing as a completely separate application
from the current web app since the test is not running as a servlet and
can't get the context from there? How do you guys test your apps? 

Thanks!
Fredrik

Unit testing web apps

Posted by Fredrik Liden <fl...@translate.com>.
Do you have any recommendations/guide lines for testing a Cayenne web
application. Do I need a combination of cactus for the web pages and
jUnit for the service layer and data objects? Would I be able to access
the cayenne data context from within the setup and tear down functions.
Or should I consider this testing as a completely separate application
from the current web app since the test is not running as a servlet and
can't get the context from there? How do you guys test your apps? 

Thanks!
Fredrik

Re: Self-join

Posted by Mike Kienenberger <mk...@gmail.com>.
Andrus,

There's a simple test case attached for that issue which I used to
verify the broken behavior beforehand and the correct behavior
afterwards.

>From the problem description given, it only affected self-joins and prefetching.

On 6/12/07, Andrus Adamchik <an...@objectstyle.org> wrote:
> Hmm... I know self-joins worked for me in the past with vanilla
> Cayenne. I haven't used such schemas in a while though. I guess I
> need to look closer at that bug report.
>
> Andrus
>
>
> On Jun 12, 2007, at 10:33 PM, Mike Kienenberger wrote:
>
> > Not really sure as I don't use them, but at least one issue with
> > self-joins is solved if you use my outer join patch for 1.2.
> >
> > https://issues.apache.org/cayenne/browse/CAY-732
> >
> >
> >
> > On 6/12/07, Fredrik Liden <fl...@translate.com> wrote:
> >> What is the status of self joins in v. 1.2.3?
> >> From the 2 posts I find in the archive seems like some people are
> >> using
> >> it.
> >> The documentation doesn't mention it.
> >> Just wondering if it's ok to use or if there are any limitations that
> >> discourages it's use?
> >>
> >> I'm have a set of nodes. I'm guessing the source node will have
> >> Source_node_id NULL or 0. And then the target nodes will refer
> >> back to
> >> the source nodes Node_id. Would it be worth using self joins here or
> >> should I just look up the target nodes based on the source nodes
> >> using
> >> regular queries and not worry about the relations?
> >>
> >> NODE
> >>
> >> Node_id (pk)
> >> Text
> >> Source_node_id (fk)
> >>
> >> Thanks!
> >> Fredrik
> >>
> >
>
>

RE: Self-join

Posted by Fredrik Liden <fl...@translate.com>.
I like Vanilla Cayenne :-)
Maybe I'll give it a try then.

Thanks,
Fredrik


-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org] 
Sent: Tuesday, June 12, 2007 2:14 PM
To: user@cayenne.apache.org
Subject: Re: Self-join

Hmm... I know self-joins worked for me in the past with vanilla  
Cayenne. I haven't used such schemas in a while though. I guess I  
need to look closer at that bug report.

Andrus


On Jun 12, 2007, at 10:33 PM, Mike Kienenberger wrote:

> Not really sure as I don't use them, but at least one issue with
> self-joins is solved if you use my outer join patch for 1.2.
>
> https://issues.apache.org/cayenne/browse/CAY-732
>
>
>
> On 6/12/07, Fredrik Liden <fl...@translate.com> wrote:
>> What is the status of self joins in v. 1.2.3?
>> From the 2 posts I find in the archive seems like some people are  
>> using
>> it.
>> The documentation doesn't mention it.
>> Just wondering if it's ok to use or if there are any limitations that
>> discourages it's use?
>>
>> I'm have a set of nodes. I'm guessing the source node will have
>> Source_node_id NULL or 0. And then the target nodes will refer  
>> back to
>> the source nodes Node_id. Would it be worth using self joins here or
>> should I just look up the target nodes based on the source nodes  
>> using
>> regular queries and not worry about the relations?
>>
>> NODE
>>
>> Node_id (pk)
>> Text
>> Source_node_id (fk)
>>
>> Thanks!
>> Fredrik
>>
>


Re: Self-join

Posted by Andrus Adamchik <an...@objectstyle.org>.
Hmm... I know self-joins worked for me in the past with vanilla  
Cayenne. I haven't used such schemas in a while though. I guess I  
need to look closer at that bug report.

Andrus


On Jun 12, 2007, at 10:33 PM, Mike Kienenberger wrote:

> Not really sure as I don't use them, but at least one issue with
> self-joins is solved if you use my outer join patch for 1.2.
>
> https://issues.apache.org/cayenne/browse/CAY-732
>
>
>
> On 6/12/07, Fredrik Liden <fl...@translate.com> wrote:
>> What is the status of self joins in v. 1.2.3?
>> From the 2 posts I find in the archive seems like some people are  
>> using
>> it.
>> The documentation doesn't mention it.
>> Just wondering if it's ok to use or if there are any limitations that
>> discourages it's use?
>>
>> I'm have a set of nodes. I'm guessing the source node will have
>> Source_node_id NULL or 0. And then the target nodes will refer  
>> back to
>> the source nodes Node_id. Would it be worth using self joins here or
>> should I just look up the target nodes based on the source nodes  
>> using
>> regular queries and not worry about the relations?
>>
>> NODE
>>
>> Node_id (pk)
>> Text
>> Source_node_id (fk)
>>
>> Thanks!
>> Fredrik
>>
>


Re: Self-join

Posted by Mike Kienenberger <mk...@gmail.com>.
Not really sure as I don't use them, but at least one issue with
self-joins is solved if you use my outer join patch for 1.2.

https://issues.apache.org/cayenne/browse/CAY-732



On 6/12/07, Fredrik Liden <fl...@translate.com> wrote:
> What is the status of self joins in v. 1.2.3?
> From the 2 posts I find in the archive seems like some people are using
> it.
> The documentation doesn't mention it.
> Just wondering if it's ok to use or if there are any limitations that
> discourages it's use?
>
> I'm have a set of nodes. I'm guessing the source node will have
> Source_node_id NULL or 0. And then the target nodes will refer back to
> the source nodes Node_id. Would it be worth using self joins here or
> should I just look up the target nodes based on the source nodes using
> regular queries and not worry about the relations?
>
> NODE
>
> Node_id (pk)
> Text
> Source_node_id (fk)
>
> Thanks!
> Fredrik
>

Self-join

Posted by Fredrik Liden <fl...@translate.com>.
What is the status of self joins in v. 1.2.3? 
>From the 2 posts I find in the archive seems like some people are using
it.
The documentation doesn't mention it.
Just wondering if it's ok to use or if there are any limitations that
discourages it's use?

I'm have a set of nodes. I'm guessing the source node will have
Source_node_id NULL or 0. And then the target nodes will refer back to
the source nodes Node_id. Would it be worth using self joins here or
should I just look up the target nodes based on the source nodes using
regular queries and not worry about the relations?

NODE

Node_id (pk)
Text
Source_node_id (fk)

Thanks!
Fredrik

Re: SQLTemplate not faulting an object

Posted by Andrus Adamchik <an...@objectstyle.org>.
Just checked this in to 3.0 branch (with Modeler support):

    https://issues.apache.org/cayenne/browse/CAY-800

so you'll be able to do this for instance:

    sqlTemplate.setColumnNamesCapitalization 
(SQLTemplate.UPPERCASE_COLUMN_NAMES)

Andrus


On Jun 5, 2007, at 2:38 PM, Andrus Adamchik wrote:

> Yeah, capitalization mismatch between the default DB behavior and  
> your mapping can bite you when you use "select *". You may have to  
> use the "#result" directive to describe all your columns:
>
>    http://cayenne.apache.org/doc/scripting-sqltemplate.html
>
>
> Since this is a pretty common and annoying problem (and presuming  
> that most users do follow some naming convention in mapping their  
> case-insensitive DB), I wonder if we should add a simple fix - two  
> methods in a SQLTemplate - "setUppercaseColumnNames",  
> "setLowercaseColumnNames"? Anybody has thoughts on that? Or is  
> there some JDBC way to achieve the same with "SELECT *" queries?
>
> Andrus
>
> On Jun 5, 2007, at 8:33 AM, Marcin Skladaniec wrote:
>
>> Hi everyone
>>
>> I'm having some troubles with SQLTemplate. The one I use is fairly  
>> simple:
>>
>> SQLTemplate query = new SQLTemplate(Student.class, "select * from  
>> Student WHERE isDeleted = 1");
>>
>> the student entity is defined by :
>>
>> 	<db-entity name="Student">
>> 		<db-attribute name="studentNumber" type="BIGINT"/>
>> ... some other fields here ...
>> 		<db-attribute name="id" type="INTEGER" isPrimaryKey="true"  
>> isMandatory="true"/>
>> 	</db-entity>
>>
>> 	<obj-entity name="Student"  
>> className="ish.oncourse.server.cayenne.Student"  
>> dbEntityName="Student"  
>> superClassName="ish.oncourse.server.cayenne.glue.CayenneDataObject" >
>> 		<qualifier><![CDATA[(isDeleted = null) or (isDeleted = 0)]]></ 
>> qualifier>
>> 		<obj-attribute name="studentNumber" type="java.lang.Long" db- 
>> attribute-path="studentNumber"/>
>> ... some other fields here ...
>> 		<obj-attribute name="id" type="java.lang.Integer" db-attribute- 
>> path="id"/>
>> 	</obj-entity>
>>
>> When the query is performed an exception is raised:
>>
>>  [java] org.apache.cayenne.CayenneRuntimeException: [v.$ 
>> {project.version} ${project.build.date} ${project.build.time}]  
>> Null value for 'id'. Snapshot: org.apache.cayenne.DataRow@b549af 
>> [values={STUDENTNUMBER=5, (Other fields in here, all in upper  
>> case), ID=241}, version=-9223372036854775761,  
>> replaces=-9223372036854775808]. Prefix: null
>> [java]     at  
>> org.apache.cayenne.access.ObjectResolver.createObjectId 
>> (ObjectResolver.java:280)
>>      [java]     at  
>> org.apache.cayenne.access.ObjectResolver.objectFromDataRow 
>> (ObjectResolver.java:206)
>>      [java]     at  
>> org.apache.cayenne.access.ObjectResolver.objectsFromDataRows 
>> (ObjectResolver.java:120)
>>      [java]     at  
>> org.apache.cayenne.access.ObjectResolver.synchronizedObjectsFromDataR 
>> ows(ObjectResolver.java:100)
>>      [java]     at  
>> org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConver 
>> sion(DataDomainQueryAction.java:433)
>>      [java]     at  
>> org.apache.cayenne.access.DataDomainQueryAction.execute 
>> (DataDomainQueryAction.java:124)
>>      [java]     at org.apache.cayenne.access.DataDomain.onQuery 
>> (DataDomain.java:722)
>>      [java]     at  
>> org.apache.cayenne.intercept.DataChannelCallbackInterceptor.onQuery 
>> (DataChannelCallbackInterceptor.java:74)
>>      [java]     at  
>> org.apache.cayenne.util.ObjectContextQueryAction.runQuery 
>> (ObjectContextQueryAction.java:282)
>>      [java]     at  
>> org.apache.cayenne.access.DataContextQueryAction.execute 
>> (DataContextQueryAction.java:59)
>>      [java]     at org.apache.cayenne.access.DataContext.onQuery 
>> (DataContext.java:1321)
>>      [java]     at  
>> org.apache.cayenne.access.DataContext.performQuery 
>> (DataContext.java:1310)
>>      [java]     at  
>> org.apache.cayenne.intercept.ObjectContextDecorator.performQuery 
>> (ObjectContextDecorator.java:98)
>>      [java]     at  
>> ish.oncourse.server.services.DataPopulationService.runService 
>> (DataPopulationService.java:688)
>>      [java]     at ish.oncourse.server.services.Service.run 
>> (Service.java:174)
>>      [java]     at java.lang.Thread.run(Thread.java:613)
>>
>> What is wrong ? Why when all my field properties are set to  
>> lowercase (like "id") the SQLTemplate returns a DataRow with only  
>> capital letters ?
>>
>>
>> I have to use the SQLTemplate since my model defines a qualifier  
>> "<qualifier><![CDATA[(isDeleted = null) or (isDeleted = 0)]]></ 
>> qualifier>" and I actually want to fetch the records with  
>> isDeleted=1. I tried different ways to waive the constraint on the  
>> data like:
>>
>> ObjEntity studentEntity = new ObjEntity 
>> ("ish.oncourse.server.cayenne.Student");
>> Expression exp = studentEntity.getDeclaredQualifier();
>> studentEntity.setDeclaredQualifier(null);
>> SelectQuery selectQuery = new SelectQuery(studentEntity);
>> studentEntity.setDeclaredQualifier(exp);
>>
>> but nothing worked. Did someone achieve it ?
>>
>> Thanks
>> Marcin
>> -------------------------->
>> ish
>> http://www.ish.com.au
>> Level 1, 30 Wilson Street Newtown 2042 Australia
>> phone +61 2 9550 5001   fax +61 2 9550 4001
>>
>>
>>
>>
>>
>
>


Re: SQLTemplate not faulting an object

Posted by Andrus Adamchik <an...@objectstyle.org>.
Yeah, capitalization mismatch between the default DB behavior and  
your mapping can bite you when you use "select *". You may have to  
use the "#result" directive to describe all your columns:

    http://cayenne.apache.org/doc/scripting-sqltemplate.html


Since this is a pretty common and annoying problem (and presuming  
that most users do follow some naming convention in mapping their  
case-insensitive DB), I wonder if we should add a simple fix - two  
methods in a SQLTemplate - "setUppercaseColumnNames",  
"setLowercaseColumnNames"? Anybody has thoughts on that? Or is there  
some JDBC way to achieve the same with "SELECT *" queries?

Andrus

On Jun 5, 2007, at 8:33 AM, Marcin Skladaniec wrote:

> Hi everyone
>
> I'm having some troubles with SQLTemplate. The one I use is fairly  
> simple:
>
> SQLTemplate query = new SQLTemplate(Student.class, "select * from  
> Student WHERE isDeleted = 1");
>
> the student entity is defined by :
>
> 	<db-entity name="Student">
> 		<db-attribute name="studentNumber" type="BIGINT"/>
> ... some other fields here ...
> 		<db-attribute name="id" type="INTEGER" isPrimaryKey="true"  
> isMandatory="true"/>
> 	</db-entity>
>
> 	<obj-entity name="Student"  
> className="ish.oncourse.server.cayenne.Student"  
> dbEntityName="Student"  
> superClassName="ish.oncourse.server.cayenne.glue.CayenneDataObject" >
> 		<qualifier><![CDATA[(isDeleted = null) or (isDeleted = 0)]]></ 
> qualifier>
> 		<obj-attribute name="studentNumber" type="java.lang.Long" db- 
> attribute-path="studentNumber"/>
> ... some other fields here ...
> 		<obj-attribute name="id" type="java.lang.Integer" db-attribute- 
> path="id"/>
> 	</obj-entity>
>
> When the query is performed an exception is raised:
>
>  [java] org.apache.cayenne.CayenneRuntimeException: [v.$ 
> {project.version} ${project.build.date} ${project.build.time}] Null  
> value for 'id'. Snapshot: org.apache.cayenne.DataRow@b549af[values= 
> {STUDENTNUMBER=5, (Other fields in here, all in upper case),  
> ID=241}, version=-9223372036854775761,  
> replaces=-9223372036854775808]. Prefix: null
> [java]     at  
> org.apache.cayenne.access.ObjectResolver.createObjectId 
> (ObjectResolver.java:280)
>      [java]     at  
> org.apache.cayenne.access.ObjectResolver.objectFromDataRow 
> (ObjectResolver.java:206)
>      [java]     at  
> org.apache.cayenne.access.ObjectResolver.objectsFromDataRows 
> (ObjectResolver.java:120)
>      [java]     at  
> org.apache.cayenne.access.ObjectResolver.synchronizedObjectsFromDataRo 
> ws(ObjectResolver.java:100)
>      [java]     at  
> org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConvers 
> ion(DataDomainQueryAction.java:433)
>      [java]     at  
> org.apache.cayenne.access.DataDomainQueryAction.execute 
> (DataDomainQueryAction.java:124)
>      [java]     at org.apache.cayenne.access.DataDomain.onQuery 
> (DataDomain.java:722)
>      [java]     at  
> org.apache.cayenne.intercept.DataChannelCallbackInterceptor.onQuery 
> (DataChannelCallbackInterceptor.java:74)
>      [java]     at  
> org.apache.cayenne.util.ObjectContextQueryAction.runQuery 
> (ObjectContextQueryAction.java:282)
>      [java]     at  
> org.apache.cayenne.access.DataContextQueryAction.execute 
> (DataContextQueryAction.java:59)
>      [java]     at org.apache.cayenne.access.DataContext.onQuery 
> (DataContext.java:1321)
>      [java]     at  
> org.apache.cayenne.access.DataContext.performQuery(DataContext.java: 
> 1310)
>      [java]     at  
> org.apache.cayenne.intercept.ObjectContextDecorator.performQuery 
> (ObjectContextDecorator.java:98)
>      [java]     at  
> ish.oncourse.server.services.DataPopulationService.runService 
> (DataPopulationService.java:688)
>      [java]     at ish.oncourse.server.services.Service.run 
> (Service.java:174)
>      [java]     at java.lang.Thread.run(Thread.java:613)
>
> What is wrong ? Why when all my field properties are set to  
> lowercase (like "id") the SQLTemplate returns a DataRow with only  
> capital letters ?
>
>
> I have to use the SQLTemplate since my model defines a qualifier  
> "<qualifier><![CDATA[(isDeleted = null) or (isDeleted = 0)]]></ 
> qualifier>" and I actually want to fetch the records with  
> isDeleted=1. I tried different ways to waive the constraint on the  
> data like:
>
> ObjEntity studentEntity = new ObjEntity 
> ("ish.oncourse.server.cayenne.Student");
> Expression exp = studentEntity.getDeclaredQualifier();
> studentEntity.setDeclaredQualifier(null);
> SelectQuery selectQuery = new SelectQuery(studentEntity);
> studentEntity.setDeclaredQualifier(exp);
>
> but nothing worked. Did someone achieve it ?
>
> Thanks
> Marcin
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001   fax +61 2 9550 4001
>
>
>
>
>