user@cayenne.apache.org Archives

Re: ParseException with EJBQL expression

2009-12-04T23:18:09Z

FYI progress made today.  I have successfully implemented a custom EJBSQL
generator and am mainly getting stuff working.

One question:  is there a valid way to express that a relationship should be
an outer join instead of inner?  I'm not finding any docs about this.

For example:

SELECT a.name,COUNT(b) FROM Artist AS a, IN (a.paintings) AS b WHERE b.year
BETWEEN 1800 AND 1900 GROUP BY a.name

I want an Artist with 0 paintings from the years 1800-1900 to still come
through as a result.  Right now of course, it is not because the inner join
removes that artist from consideration.

So close..

Thanks again for the help--
Dave


On Fri, Dec 4, 2009 at 10:09 AM, Dave Lamy  wrote:

> So one problem that I now understand is that EJBQL doesn't support
> navigating over to-many collections inline, so "foo.productStyles.taxonomy"
> would be invalid.  In order to do that you have to do this whole
> "IN(foo.productStyles) styles" bit in the FROM clause, at least according to
> the specs.
>
> I don't know if this is causing the parse problem or not.. but it does
> render the Expression.toEJBQL() rather useless.  I would need to do my own
> FROM/WHERE clause generation.
>
> I'll plug away at this and will let you know what I find out..
>
> Dave
>
>
> On Fri, Dec 4, 2009 at 8:09 AM, Dave Lamy  wrote:
>
>> I can get rid of the likeIgnoreCase and see what happens.  So I'm OK on
>> the alias part right?  In my other tests it didn't need an "as".  I've
>> mainly been concerned about whether that "doublehop"
>> (.productStyles.taxonomy) would be valid or not.
>>
>> FYI that popped straight out of an Expression.toEJBSQL().  Not sure how
>> best to handle situations like that, where the Expression supports a notion
>> that EJBSQL does not.
>>
>> On Fri, Dec 4, 2009 at 7:31 AM, Andrus Adamchik wrote:
>>
>>> "likeIgnoreCase" is not valid in EJBQL. Although the error message refers
>>> to something else... strange...
>>>
>>>
>>>
>>> On Dec 4, 2009, at 4:12 AM, Dave Lamy wrote:
>>>
>>>  Hey guys--
>>>>
>>>> I'm really just now getting into using the EJBQLQuery and am having some
>>>> difficulties.  I don't know whether I'm doing something fundamentally
>>>> wrong
>>>> or what.
>>>>
>>>> Here's my EJBQL expression that I'm trying to get parsed (running
>>>> 3.0B1):
>>>>
>>>> select COUNT(foo) from ProductCollection foo where
>>>> foo.productStyles.taxonomy likeIgnoreCase '323.%'
>>>>
>>>> Parsing this query yields the following exception:
>>>>
>>>>
>>>> org.apache.cayenne.ejbql.parser.ParseException: Encountered "
>>>> 
>>>> "foo "" at line 1, column 53.
>>>> Was expecting:
>>>>   "(" ...
>>>>
>>>>   at
>>>>
>>>> org.apache.cayenne.ejbql.parser.EJBQL.generateParseException(EJBQL.java:9419)
>>>>   at
>>>> org.apache.cayenne.ejbql.parser.EJBQL.jj_consume_token(EJBQL.java:9298)
>>>>   at
>>>>
>>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java:1933)
>>>>   at
>>>>
>>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java:1911)
>>>>   at
>>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java:1776)
>>>>   at
>>>>
>>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
>>>>   at
>>>>
>>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java:1928)
>>>>   at
>>>>
>>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java:1911)
>>>>   at
>>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java:1776)
>>>>   at
>>>>
>>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
>>>>   at org.apache.cayenne.ejbql.parser.EJBQL.where_clause(EJBQL.java:1585)
>>>>   at
>>>> org.apache.cayenne.ejbql.parser.EJBQL.select_statement(EJBQL.java:69)
>>>>   at org.apache.cayenne.ejbql.parser.EJBQL.parseQuery(EJBQL.java:41)
>>>> ...
>>>>
>>>> The statement looks legit to me.  Is there like a fundamental something
>>>> I'm
>>>> not understanding about EJBQL?  I saw some docs that showed doing this
>>>> sort
>>>> of join alias "IN" thing,
>>>>
>>>> SELECT OBJECT(e) FROM Department d, IN(d.employees) e
>>>>   WHERE d.name = ?1 AND e.salary > ?2
>>>>
>>>> My problem is that I'm using Expression.toEJBQL() to gen the where
>>>> clause..
>>>> was hoping to not have to recreate my code that generates the Expression
>>>> object.
>>>>
>>>> Help!
>>>>
>>>> Dave
>>>>
>>>
>>>
>>
>

Re: DBCPDataSourceFactory Issue

2009-12-04T22:01:16Z

I guess the easiest way is to write your own factory using Cayenne- 
provided one as a template.

BTW, Cayenne implementation of DBCPDataSourceFactory is over- 
engineered. It overlooks a simple way to configure DBCP via  
org.apache.commons.dbcp.BasicDataSource. So the factory internally  
shouldn't look as scary as it does now, and hopefully we'll take  
advantage of that during 3.1 DI refactoring.

Andrus

On Dec 4, 2009, at 9:51 PM, Michael Gentry wrote:

> I'm trying to use DBCPDataSourceFactory and load my data source
> information from a location external to the project.  I keep getting
> errors that it can't find the file.  Has anyone does this
> successfully?
>
> Thanks!
>
> mrg
>

DBCPDataSourceFactory Issue

2009-12-04T19:51:13Z

I'm trying to use DBCPDataSourceFactory and load my data source
information from a location external to the project.  I keep getting
errors that it can't find the file.  Has anyone does this
successfully?

Thanks!

mrg

Re: Selecting with an offset / paging

2009-12-04T17:20:41Z

Also Cayenne 3.0 supports offsets for all types of queries:

http://cayenne.apache.org/doc/api/org/apache/cayenne/query/SelectQuery.html#setFetchOffset(int)

Andrus

On Dec 4, 2009, at 7:12 PM, Michael Gentry wrote:

> Hi Ilya,
>
> Are you at least using a paginated query instead of a regular query?
>
> http://cayenne.apache.org/doc12/paginated-queries.html
>
> mrg
>
>
> On Fri, Dec 4, 2009 at 11:42 AM, Ilya Lazarev   
> wrote:
>> using 1.2, forgot to mention
>>
>> On Fri, Dec 4, 2009 at 5:41 PM, Ilya Lazarev   
>> wrote:
>>
>>> Hello,
>>>
>>> I have a webapp that accesses an Oralce DB to retrieve records and  
>>> do
>>> paging over the entire resultset (an expression is used that spans  
>>> multiple
>>> tables). Recently when the number of results in total adds up to  
>>> over 30000,
>>> the performance of the select query has dropped to unusable levels  
>>> (30+
>>> seconds per query). The webapp never returns all 30000 rows so  
>>> it's OK for
>>> the time being, but it certainly needs to be addressed.I wanted to  
>>> do a
>>> select with a *"where rownum > a and rownum < b" *type query, but  
>>> so far
>>> have not seen a way to do that. Does anyone have any tips how to  
>>> do this? My
>>> other option is to rewrite the retrieval using SQLTemplate and  
>>> calculate the
>>> dynamic sql based on parameters by hand, correct? Will the  
>>> resultset contain
>>> objects with their relationships that way (ie.
>>> ((TableA)result.get(0)).getToTableB() ?) or flat data rows?
>>>
>>> Thanks!
>>>
>>
>

Re: Selecting with an offset / paging

2009-12-04T17:12:44Z

Hi Ilya,

Are you at least using a paginated query instead of a regular query?

http://cayenne.apache.org/doc12/paginated-queries.html

mrg


On Fri, Dec 4, 2009 at 11:42 AM, Ilya Lazarev  wrote:
> using 1.2, forgot to mention
>
> On Fri, Dec 4, 2009 at 5:41 PM, Ilya Lazarev  wrote:
>
>> Hello,
>>
>> I have a webapp that accesses an Oralce DB to retrieve records and do
>> paging over the entire resultset (an expression is used that spans multiple
>> tables). Recently when the number of results in total adds up to over 30000,
>> the performance of the select query has dropped to unusable levels (30+
>> seconds per query). The webapp never returns all 30000 rows so it's OK for
>> the time being, but it certainly needs to be addressed.I wanted to do a
>> select with a *"where rownum > a and rownum < b" *type query, but so far
>> have not seen a way to do that. Does anyone have any tips how to do this? My
>> other option is to rewrite the retrieval using SQLTemplate and calculate the
>> dynamic sql based on parameters by hand, correct? Will the resultset contain
>> objects with their relationships that way (ie.
>> ((TableA)result.get(0)).getToTableB() ?) or flat data rows?
>>
>> Thanks!
>>
>

Re: Selecting with an offset / paging

2009-12-04T16:42:24Z

using 1.2, forgot to mention

On Fri, Dec 4, 2009 at 5:41 PM, Ilya Lazarev  wrote:

> Hello,
>
> I have a webapp that accesses an Oralce DB to retrieve records and do
> paging over the entire resultset (an expression is used that spans multiple
> tables). Recently when the number of results in total adds up to over 30000,
> the performance of the select query has dropped to unusable levels (30+
> seconds per query). The webapp never returns all 30000 rows so it's OK for
> the time being, but it certainly needs to be addressed.I wanted to do a
> select with a *"where rownum > a and rownum < b" *type query, but so far
> have not seen a way to do that. Does anyone have any tips how to do this? My
> other option is to rewrite the retrieval using SQLTemplate and calculate the
> dynamic sql based on parameters by hand, correct? Will the resultset contain
> objects with their relationships that way (ie.
> ((TableA)result.get(0)).getToTableB() ?) or flat data rows?
>
> Thanks!
>

Selecting with an offset / paging

2009-12-04T16:41:52Z

Hello,

I have a webapp that accesses an Oralce DB to retrieve records and do paging
over the entire resultset (an expression is used that spans multiple
tables). Recently when the number of results in total adds up to over 30000,
the performance of the select query has dropped to unusable levels (30+
seconds per query). The webapp never returns all 30000 rows so it's OK for
the time being, but it certainly needs to be addressed.I wanted to do a
select with a *"where rownum > a and rownum < b" *type query, but so far
have not seen a way to do that. Does anyone have any tips how to do this? My
other option is to rewrite the retrieval using SQLTemplate and calculate the
dynamic sql based on parameters by hand, correct? Will the resultset contain
objects with their relationships that way (ie.
((TableA)result.get(0)).getToTableB() ?) or flat data rows?

Thanks!

Re: ParseException with EJBQL expression

2009-12-04T16:09:20Z

So one problem that I now understand is that EJBQL doesn't support
navigating over to-many collections inline, so "foo.productStyles.taxonomy"
would be invalid.  In order to do that you have to do this whole
"IN(foo.productStyles) styles" bit in the FROM clause, at least according to
the specs.

I don't know if this is causing the parse problem or not.. but it does
render the Expression.toEJBQL() rather useless.  I would need to do my own
FROM/WHERE clause generation.

I'll plug away at this and will let you know what I find out..

Dave

On Fri, Dec 4, 2009 at 8:09 AM, Dave Lamy  wrote:

> I can get rid of the likeIgnoreCase and see what happens.  So I'm OK on the
> alias part right?  In my other tests it didn't need an "as".  I've mainly
> been concerned about whether that "doublehop" (.productStyles.taxonomy)
> would be valid or not.
>
> FYI that popped straight out of an Expression.toEJBSQL().  Not sure how
> best to handle situations like that, where the Expression supports a notion
> that EJBSQL does not.
>
> On Fri, Dec 4, 2009 at 7:31 AM, Andrus Adamchik wrote:
>
>> "likeIgnoreCase" is not valid in EJBQL. Although the error message refers
>> to something else... strange...
>>
>>
>>
>> On Dec 4, 2009, at 4:12 AM, Dave Lamy wrote:
>>
>>  Hey guys--
>>>
>>> I'm really just now getting into using the EJBQLQuery and am having some
>>> difficulties.  I don't know whether I'm doing something fundamentally
>>> wrong
>>> or what.
>>>
>>> Here's my EJBQL expression that I'm trying to get parsed (running 3.0B1):
>>>
>>> select COUNT(foo) from ProductCollection foo where
>>> foo.productStyles.taxonomy likeIgnoreCase '323.%'
>>>
>>> Parsing this query yields the following exception:
>>>
>>>
>>> org.apache.cayenne.ejbql.parser.ParseException: Encountered "
>>> 
>>> "foo "" at line 1, column 53.
>>> Was expecting:
>>>   "(" ...
>>>
>>>   at
>>>
>>> org.apache.cayenne.ejbql.parser.EJBQL.generateParseException(EJBQL.java:9419)
>>>   at
>>> org.apache.cayenne.ejbql.parser.EJBQL.jj_consume_token(EJBQL.java:9298)
>>>   at
>>>
>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java:1933)
>>>   at
>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java:1911)
>>>   at
>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java:1776)
>>>   at
>>>
>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
>>>   at
>>>
>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java:1928)
>>>   at
>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java:1911)
>>>   at
>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java:1776)
>>>   at
>>>
>>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
>>>   at org.apache.cayenne.ejbql.parser.EJBQL.where_clause(EJBQL.java:1585)
>>>   at
>>> org.apache.cayenne.ejbql.parser.EJBQL.select_statement(EJBQL.java:69)
>>>   at org.apache.cayenne.ejbql.parser.EJBQL.parseQuery(EJBQL.java:41)
>>> ...
>>>
>>> The statement looks legit to me.  Is there like a fundamental something
>>> I'm
>>> not understanding about EJBQL?  I saw some docs that showed doing this
>>> sort
>>> of join alias "IN" thing,
>>>
>>> SELECT OBJECT(e) FROM Department d, IN(d.employees) e
>>>   WHERE d.name = ?1 AND e.salary > ?2
>>>
>>> My problem is that I'm using Expression.toEJBQL() to gen the where
>>> clause..
>>> was hoping to not have to recreate my code that generates the Expression
>>> object.
>>>
>>> Help!
>>>
>>> Dave
>>>
>>
>>
>

Re: ParseException with EJBQL expression

2009-12-04T14:09:32Z

I can get rid of the likeIgnoreCase and see what happens.  So I'm OK on the
alias part right?  In my other tests it didn't need an "as".  I've mainly
been concerned about whether that "doublehop" (.productStyles.taxonomy)
would be valid or not.

FYI that popped straight out of an Expression.toEJBSQL().  Not sure how best
to handle situations like that, where the Expression supports a notion that
EJBSQL does not.

On Fri, Dec 4, 2009 at 7:31 AM, Andrus Adamchik wrote:

> "likeIgnoreCase" is not valid in EJBQL. Although the error message refers
> to something else... strange...
>
>
>
> On Dec 4, 2009, at 4:12 AM, Dave Lamy wrote:
>
>  Hey guys--
>>
>> I'm really just now getting into using the EJBQLQuery and am having some
>> difficulties.  I don't know whether I'm doing something fundamentally
>> wrong
>> or what.
>>
>> Here's my EJBQL expression that I'm trying to get parsed (running 3.0B1):
>>
>> select COUNT(foo) from ProductCollection foo where
>> foo.productStyles.taxonomy likeIgnoreCase '323.%'
>>
>> Parsing this query yields the following exception:
>>
>>
>> org.apache.cayenne.ejbql.parser.ParseException: Encountered " 
>> "foo "" at line 1, column 53.
>> Was expecting:
>>   "(" ...
>>
>>   at
>>
>> org.apache.cayenne.ejbql.parser.EJBQL.generateParseException(EJBQL.java:9419)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.jj_consume_token(EJBQL.java:9298)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java:1933)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java:1911)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java:1776)
>>   at
>>
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java:1928)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java:1911)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java:1776)
>>   at
>>
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
>>   at org.apache.cayenne.ejbql.parser.EJBQL.where_clause(EJBQL.java:1585)
>>   at org.apache.cayenne.ejbql.parser.EJBQL.select_statement(EJBQL.java:69)
>>   at org.apache.cayenne.ejbql.parser.EJBQL.parseQuery(EJBQL.java:41)
>> ...
>>
>> The statement looks legit to me.  Is there like a fundamental something
>> I'm
>> not understanding about EJBQL?  I saw some docs that showed doing this
>> sort
>> of join alias "IN" thing,
>>
>> SELECT OBJECT(e) FROM Department d, IN(d.employees) e
>>   WHERE d.name = ?1 AND e.salary > ?2
>>
>> My problem is that I'm using Expression.toEJBQL() to gen the where
>> clause..
>> was hoping to not have to recreate my code that generates the Expression
>> object.
>>
>> Help!
>>
>> Dave
>>
>
>

Re: ParseException with EJBQL expression

2009-12-04T13:31:48Z

"likeIgnoreCase" is not valid in EJBQL. Although the error message  
refers to something else... strange...


On Dec 4, 2009, at 4:12 AM, Dave Lamy wrote:

> Hey guys--
>
> I'm really just now getting into using the EJBQLQuery and am having  
> some
> difficulties.  I don't know whether I'm doing something  
> fundamentally wrong
> or what.
>
> Here's my EJBQL expression that I'm trying to get parsed (running  
> 3.0B1):
>
> select COUNT(foo) from ProductCollection foo where
> foo.productStyles.taxonomy likeIgnoreCase '323.%'
>
> Parsing this query yields the following exception:
>
>
> org.apache.cayenne.ejbql.parser.ParseException: Encountered "  
> 
> "foo "" at line 1, column 53.
> Was expecting:
>    "(" ...
>
>    at
> org 
> .apache.cayenne.ejbql.parser.EJBQL.generateParseException(EJBQL.java: 
> 9419)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.jj_consume_token(EJBQL.java: 
> 9298)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java: 
> 1933)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java: 
> 1911)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java: 
> 1776)
>    at
> org 
> .apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java: 
> 1738)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java: 
> 1928)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java: 
> 1911)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java: 
> 1776)
>    at
> org 
> .apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java: 
> 1738)
>    at org.apache.cayenne.ejbql.parser.EJBQL.where_clause(EJBQL.java: 
> 1585)
>    at  
> org.apache.cayenne.ejbql.parser.EJBQL.select_statement(EJBQL.java:69)
>    at org.apache.cayenne.ejbql.parser.EJBQL.parseQuery(EJBQL.java:41)
> ...
>
> The statement looks legit to me.  Is there like a fundamental  
> something I'm
> not understanding about EJBQL?  I saw some docs that showed doing  
> this sort
> of join alias "IN" thing,
>
> SELECT OBJECT(e) FROM Department d, IN(d.employees) e
>    WHERE d.name = ?1 AND e.salary > ?2
>
> My problem is that I'm using Expression.toEJBQL() to gen the where  
> clause..
> was hoping to not have to recreate my code that generates the  
> Expression
> object.
>
> Help!
>
> Dave

Re: ParseException with EJBQL expression

2009-12-04T13:28:47Z

Umm sorry, "foo" is the alias..

On Dec 4, 2009, at 3:26 PM, Andrus Adamchik wrote:

> Right now our parser requires aliases for entities:
>
>> select COUNT(a) from ProductCollection foo as a where
>> a.productStyles.taxonomy likeIgnoreCase '323.%'
>
> On Dec 4, 2009, at 4:12 AM, Dave Lamy wrote:
>
>> Hey guys--
>>
>> I'm really just now getting into using the EJBQLQuery and am having  
>> some
>> difficulties.  I don't know whether I'm doing something  
>> fundamentally wrong
>> or what.
>>
>> Here's my EJBQL expression that I'm trying to get parsed (running  
>> 3.0B1):
>>
>> select COUNT(foo) from ProductCollection foo where
>> foo.productStyles.taxonomy likeIgnoreCase '323.%'
>>
>> Parsing this query yields the following exception:
>>
>>
>> org.apache.cayenne.ejbql.parser.ParseException: Encountered "  
>> 
>> "foo "" at line 1, column 53.
>> Was expecting:
>>   "(" ...
>>
>>   at
>> org 
>> .apache 
>> .cayenne.ejbql.parser.EJBQL.generateParseException(EJBQL.java:9419)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.jj_consume_token(EJBQL.java: 
>> 9298)
>>   at
>> org 
>> .apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java: 
>> 1933)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java: 
>> 1911)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java: 
>> 1776)
>>   at
>> org 
>> .apache 
>> .cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
>>   at
>> org 
>> .apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java: 
>> 1928)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java: 
>> 1911)
>>   at
>> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java: 
>> 1776)
>>   at
>> org 
>> .apache 
>> .cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
>>   at org.apache.cayenne.ejbql.parser.EJBQL.where_clause(EJBQL.java: 
>> 1585)
>>   at  
>> org.apache.cayenne.ejbql.parser.EJBQL.select_statement(EJBQL.java:69)
>>   at org.apache.cayenne.ejbql.parser.EJBQL.parseQuery(EJBQL.java:41)
>> ...
>>
>> The statement looks legit to me.  Is there like a fundamental  
>> something I'm
>> not understanding about EJBQL?  I saw some docs that showed doing  
>> this sort
>> of join alias "IN" thing,
>>
>> SELECT OBJECT(e) FROM Department d, IN(d.employees) e
>>   WHERE d.name = ?1 AND e.salary > ?2
>>
>> My problem is that I'm using Expression.toEJBQL() to gen the where  
>> clause..
>> was hoping to not have to recreate my code that generates the  
>> Expression
>> object.
>>
>> Help!
>>
>> Dave
>
>

Re: ParseException with EJBQL expression

2009-12-04T13:26:22Z

Right now our parser requires aliases for entities:

> select COUNT(a) from ProductCollection foo as a where
> a.productStyles.taxonomy likeIgnoreCase '323.%'

On Dec 4, 2009, at 4:12 AM, Dave Lamy wrote:

> Hey guys--
>
> I'm really just now getting into using the EJBQLQuery and am having  
> some
> difficulties.  I don't know whether I'm doing something  
> fundamentally wrong
> or what.
>
> Here's my EJBQL expression that I'm trying to get parsed (running  
> 3.0B1):
>
> select COUNT(foo) from ProductCollection foo where
> foo.productStyles.taxonomy likeIgnoreCase '323.%'
>
> Parsing this query yields the following exception:
>
>
> org.apache.cayenne.ejbql.parser.ParseException: Encountered "  
> 
> "foo "" at line 1, column 53.
> Was expecting:
>    "(" ...
>
>    at
> org 
> .apache.cayenne.ejbql.parser.EJBQL.generateParseException(EJBQL.java: 
> 9419)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.jj_consume_token(EJBQL.java: 
> 9298)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java: 
> 1933)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java: 
> 1911)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java: 
> 1776)
>    at
> org 
> .apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java: 
> 1738)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java: 
> 1928)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java: 
> 1911)
>    at
> org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java: 
> 1776)
>    at
> org 
> .apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java: 
> 1738)
>    at org.apache.cayenne.ejbql.parser.EJBQL.where_clause(EJBQL.java: 
> 1585)
>    at  
> org.apache.cayenne.ejbql.parser.EJBQL.select_statement(EJBQL.java:69)
>    at org.apache.cayenne.ejbql.parser.EJBQL.parseQuery(EJBQL.java:41)
> ...
>
> The statement looks legit to me.  Is there like a fundamental  
> something I'm
> not understanding about EJBQL?  I saw some docs that showed doing  
> this sort
> of join alias "IN" thing,
>
> SELECT OBJECT(e) FROM Department d, IN(d.employees) e
>    WHERE d.name = ?1 AND e.salary > ?2
>
> My problem is that I'm using Expression.toEJBQL() to gen the where  
> clause..
> was hoping to not have to recreate my code that generates the  
> Expression
> object.
>
> Help!
>
> Dave

Re: Referencing ID fields in EJBQL

2009-12-04T13:16:52Z

Thanks Andrus.  I had actually pulled the trunk and was toying around with
adding an hql-esque .id "magic" field that would automatically reference a
single PK using your synthetic PK ObjAttribute stuff.  I nearly had it
working when I started hitting the problem mentioned in my other post.  I
don't suppose you might have any insight into that one.. :-)  It's a much
more pressing problem for me at the moment.

Dave

On Fri, Dec 4, 2009 at 2:39 AM, Andrus Adamchik wrote:

> Yeah, in 3.0 EJBQL is somewhat of an implant from the JPA world, so it
> lacks a few Cayenne conveniences. I am certainly in favor to add support for
> "db:" expressions in the future versions (and the patches are welcomed).
>
> For now the option is to map PK column as the object property. Other than
> exposing it to the world, this shouldn't have any side effects. Auto
> generation will still work, etc.
>
> Andrus
>
>
> On Dec 4, 2009, at 12:05 AM, Dave Lamy wrote:
>
>  Hello all--
>>
>> I am curious to know how (if possible) to reference a PK field using
>> EJBQL.
>>
>> I tried using the normal expression "db:" syntax but as I saw in the
>> source
>> this won't work.  EJBQLPathTranslator.processLastPathComponent() appears
>> to
>> assume that the last part of any path will reference either an
>> ObjAttribute
>> or an ObjRelationship, and will throw an IllegalStateException if neither
>> of
>> these are the case.
>>
>> I'd like to have access to the PK field for a couple of purposes.  One,
>> when
>> doing COUNT queries it is faster to do a COUNT(PK) than a COUNT(*).
>> Furthermore, I want to be able to essentially group aggregate function
>> results by objects, which would be impractical to do using the OBJECT(e)
>> notation, so the plan was to perform the group query using IDs and then
>> fill
>> in the results with objects on the way out.
>>
>> Since the call from processLastPathComponent() to
>> processTerminatingAttribute() just resolves into a DbAttribute and thus a
>> column name anyway, wouldn't it be rather simple patch to do a "db:" check
>> on the path component and presume a DB column name instead of an
>> ObjAttribute name?  I imagine I may be oversimplifying the situation, but
>> if
>> not and there is agreement on the method I don't mind doing the patch.
>>
>> Of course, if there is an alternative way to reference PKs that I'm
>> unaware
>> of please enlighten me :-).
>>
>> Thanks--
>> Dave
>>
>
>

Re: Referencing ID fields in EJBQL

2009-12-04T08:39:06Z

Yeah, in 3.0 EJBQL is somewhat of an implant from the JPA world, so it  
lacks a few Cayenne conveniences. I am certainly in favor to add  
support for "db:" expressions in the future versions (and the patches  
are welcomed).

For now the option is to map PK column as the object property. Other  
than exposing it to the world, this shouldn't have any side effects.  
Auto generation will still work, etc.

Andrus

On Dec 4, 2009, at 12:05 AM, Dave Lamy wrote:

> Hello all--
>
> I am curious to know how (if possible) to reference a PK field using  
> EJBQL.
>
> I tried using the normal expression "db:" syntax but as I saw in the  
> source
> this won't work.  EJBQLPathTranslator.processLastPathComponent()  
> appears to
> assume that the last part of any path will reference either an  
> ObjAttribute
> or an ObjRelationship, and will throw an IllegalStateException if  
> neither of
> these are the case.
>
> I'd like to have access to the PK field for a couple of purposes.   
> One, when
> doing COUNT queries it is faster to do a COUNT(PK) than a COUNT(*).
> Furthermore, I want to be able to essentially group aggregate function
> results by objects, which would be impractical to do using the  
> OBJECT(e)
> notation, so the plan was to perform the group query using IDs and  
> then fill
> in the results with objects on the way out.
>
> Since the call from processLastPathComponent() to
> processTerminatingAttribute() just resolves into a DbAttribute and  
> thus a
> column name anyway, wouldn't it be rather simple patch to do a "db:"  
> check
> on the path component and presume a DB column name instead of an
> ObjAttribute name?  I imagine I may be oversimplifying the  
> situation, but if
> not and there is agreement on the method I don't mind doing the patch.
>
> Of course, if there is an alternative way to reference PKs that I'm  
> unaware
> of please enlighten me :-).
>
> Thanks--
> Dave

ParseException with EJBQL expression

2009-12-04T02:12:28Z

Hey guys--

I'm really just now getting into using the EJBQLQuery and am having some
difficulties.  I don't know whether I'm doing something fundamentally wrong
or what.

Here's my EJBQL expression that I'm trying to get parsed (running 3.0B1):

select COUNT(foo) from ProductCollection foo where
foo.productStyles.taxonomy likeIgnoreCase '323.%'

Parsing this query yields the following exception:


org.apache.cayenne.ejbql.parser.ParseException: Encountered " 
"foo "" at line 1, column 53.
Was expecting:
    "(" ...

    at
org.apache.cayenne.ejbql.parser.EJBQL.generateParseException(EJBQL.java:9419)
    at
org.apache.cayenne.ejbql.parser.EJBQL.jj_consume_token(EJBQL.java:9298)
    at
org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java:1933)
    at
org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java:1911)
    at
org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java:1776)
    at
org.apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
    at
org.apache.cayenne.ejbql.parser.EJBQL.conditional_primary(EJBQL.java:1928)
    at
org.apache.cayenne.ejbql.parser.EJBQL.conditional_factor(EJBQL.java:1911)
    at
org.apache.cayenne.ejbql.parser.EJBQL.conditional_term(EJBQL.java:1776)
    at
org.apache.cayenne.ejbql.parser.EJBQL.conditional_expression(EJBQL.java:1738)
    at org.apache.cayenne.ejbql.parser.EJBQL.where_clause(EJBQL.java:1585)
    at org.apache.cayenne.ejbql.parser.EJBQL.select_statement(EJBQL.java:69)
    at org.apache.cayenne.ejbql.parser.EJBQL.parseQuery(EJBQL.java:41)
...

The statement looks legit to me.  Is there like a fundamental something I'm
not understanding about EJBQL?  I saw some docs that showed doing this sort
of join alias "IN" thing,

SELECT OBJECT(e) FROM Department d, IN(d.employees) e
    WHERE d.name = ?1 AND e.salary > ?2

My problem is that I'm using Expression.toEJBQL() to gen the where clause..
was hoping to not have to recreate my code that generates the Expression
object.

Help!

Dave

Referencing ID fields in EJBQL

2009-12-03T22:05:31Z

Hello all--

I am curious to know how (if possible) to reference a PK field using EJBQL.

I tried using the normal expression "db:" syntax but as I saw in the source
this won't work.  EJBQLPathTranslator.processLastPathComponent() appears to
assume that the last part of any path will reference either an ObjAttribute
or an ObjRelationship, and will throw an IllegalStateException if neither of
these are the case.

I'd like to have access to the PK field for a couple of purposes.  One, when
doing COUNT queries it is faster to do a COUNT(PK) than a COUNT(*).
Furthermore, I want to be able to essentially group aggregate function
results by objects, which would be impractical to do using the OBJECT(e)
notation, so the plan was to perform the group query using IDs and then fill
in the results with objects on the way out.

Since the call from processLastPathComponent() to
processTerminatingAttribute() just resolves into a DbAttribute and thus a
column name anyway, wouldn't it be rather simple patch to do a "db:" check
on the path component and presume a DB column name instead of an
ObjAttribute name?  I imagine I may be oversimplifying the situation, but if
not and there is agreement on the method I don't mind doing the patch.

Of course, if there is an alternative way to reference PKs that I'm unaware
of please enlighten me :-).

Thanks--
Dave

Problem with joining two tables, base one empty.

2009-12-03T22:04:02Z

Hi,

I've got a problem with a join-query which I can not convert to a set of 
objects the way I'd like.
The problem is that the base table is empty.

I'm querying the following 2 tables:

SetInstance    
-----------
setId          PK
setInstanceId  PK

              
CollectionSetInstance
-----------
setId            PK
setInstanceId    PK
collectionId     PK
number...          

I want to display a list of all SetInstances to the user, including the 
number of times he has the SetInstance (field number...) in his Collection.

The table CollectionSetInstance is initially empty.
When a user adds a SetInstance to his Collection a row in 
CollectionSetInstance is added.
When the user wants to add another SetInstance to his Collection, the 
field 'number' is increased.

Things I've tried:
1. My first attempt was to query SetInstance en outer join 
CollectionSetInstance.
   This retrieves the correct result (all setInstances), but Cayenne 
forces me to add a relation from SetInstance to CollectionSetInstance?
   This is not what I want, because functionally there is not 
relationship between SetInstance and CollectionSetInstance.

2. I've also tried to use a SQLTemplate query and convert that to the 
desired object.
   This has not worked because Cayenne gives me an exception.
   See this code:

SQLTemplate query = new SQLTemplate(CollectionSetInstance.class,
    "SELECT " +
        "SI.setId, " +
        "SI.setInstanceId, " +
        "CSI.collectionId, " +
        "CSI.number " +
     "FROM SetInstance SI " +
     "LEFT OUTER JOIN CollectionSetInstance CSI ON " +
        "CSI.setId = SCI.setId " +
        "AND CSI.setInstanceId = SCI.setInstanceId " );
 
EntityResult result = new EntityResult(CollectionSetCardInstance.class);
result.addDbField(CollectionSetCardInstance.SET_ID_PK_COLUMN, "setId");
result.addDbField(CollectionSetCardInstance.SET_INSTANCE_ID_PK_COLUMN, 
"setInstanceId");
result.addDbField(CollectionSetCardInstance.COLLECTION_ID_PK_COLUMN, 
"collectionId");
result.addObjectField(CollectionSetCardInstance.NUMBER_PROPERTY, "number");

List list = context.performQuery(query);


Can anyone help me out on this one? If you need any more information, 
let me know.

Greets,
Elt

Not polymorphic query

2009-12-03T18:46:14Z

Hi Guys,   
(In Cayenne 2.0 version) Considering the hierarchical class tree to single 
table example, if I perform this kind of not-polymorphic query:    
  
SelectQuery query = new SelectQuery( Manager.class );  
  
I receive this error : "No inheritance - there must be only one override 
set"   
It's my error or I can't do a not-polymorphic query at all?   
__  
Domenico

Re: delete new --> transient?

2009-12-01T23:14:59Z

On 02/12/2009, at 9:35 AM, Weddle, Anthony wrote:

> -----Original Message-----
> From: Lachlan Deck [mailto:lachlan.deck@gmail.com]
> 
>> Now, without creating objects in the first place you both have nothing to
>> validate (validateForSave) nor can you roll-back changes (should this have
>> been a previously persisted object). In either case, the controller/ui
>> doesn't care...
> 
> OK. So the main problem is roll-back.

It's 'a' feature. Not the main/only problem.

> Obviously, to validate an object, you need the object but there's no need to validate
a deleted object,

Of course. It won't validate whilst transient, though validateForDelete is relevant otherwise.

> I would have thought (and, presumably, it wouldn't be deleted until analysed).

To provide immediate user feedback, validation is triggered after each event (for us).

> So what is the roll-back point? Is it the last persisted state of the objects?

Sure.

> If so, then you don't need to know the current state of the objects and can create whole
new objects or read them from the database, as you did at the start of the processes.

That's not the problem I'm solving. But sure, if someone hits cancel then that will occur.

> If it is some intermediate state, that you need to roll back to, then you should store
that state in the program, not the object context, as far as I can tell.

I've got it working using Cayenne as I believe it should (though still not 100% that it covers
all transient possibilities). Intermixing non-object state and custom state wouldn't be preferable.

> The context is there because of Cayenne, not because of the logic in your program.

Well.... on this I'll admit that I come from EOF where this particular action/case didn't
require as much, um, thinking :-) To put it another way, I understand your logic here I just
don't completely agree with it :)

> Perhaps you can delay any deletion, in context terms, until you know what is ultimately
going to be saved.

That's not practical. If a save action is triggered that needs further work to be done by
the user (requiring a subsequent save) at which point are the deletions inserted? It doesn't
work.

>>> From the program's point of view, it's clear that TRANSIENT can be
>>> treated exactly the same as DELETED, since they both mean that some
>>> persistable object previously created in the program has subsequently
>>> been deleted by the program.
> 
>> My point (and clarifying question, however) is that if TRANSIENT does not
>> always mean that ... and it's possible for objects to be transient in
>> other ways then that's not good enough. It'll do for now - but I'd like to
>> put code in the entity that works in all circumstances and not just for
>> this particular case.
> 
> Ah, well, if you really do need to use context state for your code, then that would have
to be the question to those that know: what situations can result in an object state of TRANSIENT?
Maybe you can confidently assume that TRANSIENT is the same as DELETED, from the program's
point of view. If not, then you'll have to avoid using the context for the purposes of your
application's logic.

Certainly I'd have to handle it otherwise... which would be a shame for it diminishes the
transparency of dealing with creating/deleting/updating objects no matter their destination.

>>> From the database's point of view, the states can't be treated the same
>>> way; the DELETED object has to be deleted from the database, the
>>> TRANSIENT object was never in the database and can be ignored.
> 
>> That's the easy part, sure. But from user-code's point of view, we don't
>> care about the database. It's an abstraction. :-) Thinking in terms of the
>> database when using an orm ain't best practice (of course you need to at
>> times). Think in terms of objects.
> 
> Indeed. By the same token, it is perhaps unwise to use something (the object context)
that exists purely because of the persistence framework, unless you are strictly coding persistence
logic.

We are strictly coding persistence logic. Even sql has conditional statements that may or
may not cause alterations to any rows... that's the key point that imho you're missing...

> If you ever change the persistence framework, it may be hard to untangle the old one
from your code.

That's always going to be true I'm afraid.

Anyway, thanks for your input.

with regards,
--

Lachlan Deck

RE: delete new --> transient?

2009-12-01T22:35:44Z

-----Original Message-----
From: Lachlan Deck [mailto:lachlan.deck@gmail.com]

> Now, without creating objects in the first place you both have nothing to
> validate (validateForSave) nor can you roll-back changes (should this have
> been a previously persisted object). In either case, the controller/ui
> doesn't care...

OK. So the main problem is roll-back. Obviously, to validate an object, you need the object
but there's no need to validate a deleted object, I would have thought (and, presumably, it
wouldn't be deleted until analysed). So what is the roll-back point? Is it the last persisted
state of the objects? If so, then you don't need to know the current state of the objects
and can create whole new objects or read them from the database, as you did at the start of
the processes. If it is some intermediate state, that you need to roll back to, then you should
store that state in the program, not the object context, as far as I can tell. The context
is there because of Cayenne, not because of the logic in your program. Perhaps you can delay
any deletion, in context terms, until you know what is ultimately going to be saved.

>> From the program's point of view, it's clear that TRANSIENT can be
>> treated exactly the same as DELETED, since they both mean that some
>> persistable object previously created in the program has subsequently
>> been deleted by the program.

> My point (and clarifying question, however) is that if TRANSIENT does not
> always mean that ... and it's possible for objects to be transient in
> other ways then that's not good enough. It'll do for now - but I'd like to
> put code in the entity that works in all circumstances and not just for
> this particular case.

Ah, well, if you really do need to use context state for your code, then that would have to
be the question to those that know: what situations can result in an object state of TRANSIENT?
Maybe you can confidently assume that TRANSIENT is the same as DELETED, from the program's
point of view. If not, then you'll have to avoid using the context for the purposes of your
application's logic.

>> From the database's point of view, the states can't be treated the same
>> way; the DELETED object has to be deleted from the database, the
>> TRANSIENT object was never in the database and can be ignored.

> That's the easy part, sure. But from user-code's point of view, we don't
> care about the database. It's an abstraction. :-) Thinking in terms of the
> database when using an orm ain't best practice (of course you need to at
> times). Think in terms of objects.

Indeed. By the same token, it is perhaps unwise to use something (the object context) that
exists purely because of the persistence framework, unless you are strictly coding persistence
logic. If you ever change the persistence framework, it may be hard to untangle the old one
from your code.

Tony



NOTICE - This message and any attached files may contain information that is confidential,
legally privileged or proprietary. It is intended only for use by the intended recipient.
If you are not the intended recipient or the person responsible for delivering the message
to the intended recipient, be advised that you have received this message in error. Any dissemination,
copying, use or re-transmission of this message or attachment, or the disclosure of any information
therein, is strictly forbidden. BlueScope Steel Limited does not represent or guarantee that
this message or attachment is free of errors, virus or interference.

If you have received this message in error please notify the sender immediately and delete
the message. Any views expressed in this email are not necessarily the views of BlueScope
Steel Limited.

Re: delete new --> transient?

2009-12-01T22:01:41Z

On 02/12/2009, at 5:09 AM, Weddle, Anthony wrote:

> The confusing thing, in this exchange is why Lachlan would be concerned about an object
which, on the face of it, should never have been constructed (since it was created and then
deleted, before it was ever persisted), or why he would want to create objects to replace
those that had been deleted.

Perhaps a real example will help clear up any confusion here. This is for ROP, btw.

So we have an interface which presents to the user a Payslip with a series of (i.e., toMany)
paylines. Depending on the information supplied per-line the line will either be discarded
or included. Unlike the web (at least web 1.0) this state can toggle frequently.

Now, without creating objects in the first place you both have nothing to validate (validateForSave)
nor can you roll-back changes (should this have been a previously persisted object). In either
case, the controller/ui doesn't care...

My point (and clarifying question, however) is that if TRANSIENT does not always mean that
... and it's possible for objects to be transient in other ways then that's not good enough.
It'll do for now - but I'd like to put code in the entity that works in all circumstances
and not just for this particular case.

> From the database's point of view, the states can't be treated the same way; the DELETED
object has to be deleted from the database, the TRANSIENT object was never in the database
and can be ignored.

That's the easy part, sure. But from user-code's point of view, we don't care about the database.
It's an abstraction. :-) Thinking in terms of the database when using an orm ain't best practice
(of course you need to at times). Think in terms of objects.

with regards,
--

Lachlan Deck

RE: delete new --> transient?

2009-12-01T18:09:37Z

The confusing thing, in this exchange is why Lachlan would be concerned about an object which,
on the face of it, should never have been constructed (since it was created and then deleted,
before it was ever persisted), or why he would want to create objects to replace those that
had been deleted.

>From the program's point of view, it's clear that TRANSIENT can be treated exactly the
same as DELETED, since they both mean that some persistable object previously created in the
program has subsequently been deleted by the program. From the database's point of view, the
states can't be treated the same way; the DELETED object has to be deleted from the database,
the TRANSIENT object was never in the database and can be ignored.

Tony

NOTICE - This message and any attached files may contain information that is confidential,
legally privileged or proprietary. It is intended only for use by the intended recipient.
If you are not the intended recipient or the person responsible for delivering the message
to the intended recipient, be advised that you have received this message in error. Any dissemination,
copying, use or re-transmission of this message or attachment, or the disclosure of any information
therein, is strictly forbidden. BlueScope Steel Limited does not represent or guarantee that
this message or attachment is free of errors, virus or interference.

If you have received this message in error please notify the sender immediately and delete
the message. Any views expressed in this email are not necessarily the views of BlueScope
Steel Limited.

Re: delete new --> transient?

2009-12-01T14:54:04Z

On Mon, Nov 30, 2009 at 5:40 PM, Lachlan Deck  wrote:
> On 28/11/2009, at 2:01 AM, Michael Gentry wrote:
>> On Thu, Nov 26, 2009 at 12:52 PM, Lachlan Deck  wrote:
>>> But this still means that there's no 'general purpose' method that I'm aware
of (e.g., in Cayenne 'the new static helper' ... ah, see, if you'd called it CayenneUtils
or PersistentUtils there'd be no need for further clarification of what Cayenne refers to
via email ;-) �which answers the basic question: 'is this object marked for deletion (regardless
of whether it was previously persisted)?'
>>
>> Well, an object should only be marked for deletion if it needs to be
>> deleted (it exists in the DB).
>
> This all depends on what 'deleted' means. If deleted were strictly for persisted objects
as you suggest then why is deleteObject the method used to make transient those objects for
which the action of deleting does not apply?

The DataContext doesn't require the user to figure out if an object
has been persisted before they call deleteObject() on it.  Nor does
the DataContext throw an exception if they call deleteObject() on a
NEW object.  The user clearly specified they no longer wanted the
object to be stored by calling deleteObject() so the DataContext marks
it as TRANSIENT if it has never been persisted or DELETED if it has
been persisted.  The commitChanges() will ignore the TRANSIENT objects
in the DataContext.

> The problem is that you cannot tell the difference between deleted transients and non-deleted
transients by looking at its state. Is there something in the framework that tells me that
an object was previously added to the context but was afterwards 'deleted' from it and is
now marked as transient?

I'm not exactly sure why you care if the TRANSIENT object had
deleteObject() called on it or not.  In general practice, though, the
object will not be TRANSIENT *unless* you call deleteObject() on it
and it is a brand new object.  One typically does not call
setPersistenceState() on objects.  And one typically creates the
object inside the DataContext (calling newObject()), which gives it a
NEW state initially.  If it has a persistence state of DELETED, you
know it was previously persisted.

>>> I simply want to know if an object is marked for deletion within the context.
It should be simple like the question itself. :) � �And to answer the question, because I
need to know at a later point whether to replace the object with a new one.

An object is marked for deletion, from the physical database, if the
persistence state is DELETED.

>> If an object's persistence state is set to DELETED,
>> then the DC knows it needs to issue a DELETE to the DB on
>> commitChanges()
>
> Are you saying that it has no knowledge otherwise as to whether the object was previously
persisted?
>
> It could also 'know' that if an object's persistence state is set to deleted and the
object was not previously persisted then it issues no sql. :-)

The persistence state variable is used to identify this information.
TRANSIENT = not persisted (or persistable).

> As I understand it, an OC exists to abstract parent object stores from the user.. where
that parent object store may or may not necessarily be a database. But this is all besides
the point.

The ObjectContext/DataContext does more than abstract the backing
store.  It provides a workspace or sandbox for changes to be made and
then manages those changes within a transaction.  If you throw away
the context, no changes are done.  To me it is more like checking out
code from a repository (such as Subversion) into a workarea.  You can
checkout as many workareas (or contexts -- one or more for each user)
as you want and make changes in them, but unless you commit them, the
repository (or database) doesn't get updated and no one else will see
those changes.

> I'm just asking the question as to whether cayenne provides the information I'm after.

I think Cayenne, especially in practical terms, tells you what you want.

Hope that helps somewhat ...

mrg

Re: delete new --> transient?

2009-11-30T22:40:52Z

On 28/11/2009, at 2:01 AM, Michael Gentry wrote:

> On Thu, Nov 26, 2009 at 12:52 PM, Lachlan Deck  wrote:
>> On 27/11/2009, at 2:24 AM, Andrey Razumovsky wrote:
>> 
>>> Because for deleted objects DELETE query will be forced, and if you create
>>> (register), then delete (unregister) an object it looks like as if it was
>>> never registered in context.
>> 
>> This seems (to me, at least) to be implementation details of the framework that's
overly exposed to general users ('cause you have to know the implementation details in order
to make any use of those persistence states in any meaningful way.... e.g., what does transient
mean? Well it depends.... What does deleted mean? Again it depends on other conditions.).
Perhaps then PersistenceState should be private to the framework.
> 
> Sometimes application code needs access to this and making it private
> wouldn't help that matter.

Sure - it can be convenient to have access to internals.

>> But this still means that there's no 'general purpose' method that I'm aware of (e.g.,
in Cayenne 'the new static helper' ... ah, see, if you'd called it CayenneUtils or PersistentUtils
there'd be no need for further clarification of what Cayenne refers to via email ;-)  which
answers the basic question: 'is this object marked for deletion (regardless of whether it
was previously persisted)?'
> 
> Well, an object should only be marked for deletion if it needs to be
> deleted (it exists in the DB).

This all depends on what 'deleted' means. If deleted were strictly for persisted objects as
you suggest then why is deleteObject the method used to make transient those objects for which
the action of deleting does not apply?

> So Cayenne is working properly in this
> regard.

I'm not suggesting it's not behaving as expected.

> If an object has never been persisted (does NOT exist in the
> DB), then it is marked as transient if you delete it.

The problem is that you cannot tell the difference between deleted transients and non-deleted
transients by looking at its state. Is there something in the framework that tells me that
an object was previously added to the context but was afterwards 'deleted' from it and is
now marked as transient?

>> I simply want to know if an object is marked for deletion within the context. It
should be simple like the question itself. :)    And to answer the question, because I need
to know at a later point whether to replace the object with a new one.
> 
> By context I assume you mean data/object context.

Correct.

> My previous comment
> still applies.  :-)  The DataContext needs to know what to do when you
> commitChanges().

Of course it does.

> If an object's persistence state is set to DELETED,
> then the DC knows it needs to issue a DELETE to the DB on
> commitChanges()

Are you saying that it has no knowledge otherwise as to whether the object was previously
persisted?

It could also 'know' that if an object's persistence state is set to deleted and the object
was not previously persisted then it issues no sql. :-)

> Here is TRANSIENT:
> 
>    /**
>     * Describes a state of an object not registered with
> DataContext/ObjectContext, and
>     * therefore having no persistence features.
>     */
>    public static final int TRANSIENT = 1;
> 
> If you register an object with a DC and then delete it (without ever
> persisting it), then it becomes TRANSIENT.  If you register an object
> with a DC, commit it, then delete it, it becomes DELETED.  Keep in
> mind the DC exists to manage your objects for committing changes to
> the DB, not to track general Java usage (such as removing an object
> from a collection).

As I understand it, an OC exists to abstract parent object stores from the user.. where that
parent object store may or may not necessarily be a database. But this is all besides the
point. 

I'm just asking the question as to whether cayenne provides the information I'm after.

with regards,
--

Lachlan Deck

Re: Exception Deleting DataObject with to-many relationship

2009-11-27T16:34:45Z

Michael,

> I was just trying to figure out where the salesOrderList property was in your model,
per this error:


Good point.  There is a SalesOrderList Relationship defined for the the Customer record (with
a reverse relationship of Customer).

I checked the ObjEntity config for the Customer and here is the entry

	Name: salesOrderList
	Target:  SalesOrder
	Sematics: to many, list
	Delete Rule: Nullify
	Used For Locking: not checked

I set the Delete rule to "Nullify" thinking that there may come a time to delete the Customer
record while retaining the SalesOrder record.  (Also I noticed that the Delete Rule for the
SaleOrder - orderitemList is set to "Cascade", but MySQL doesn't seem to want to cascade delete
the OrderItems when I delete a SalesOrder).

I would expect from my understanding of the Modeler is that when a Customer is deleted via
Cayenne, that the SalesOrder - customerOID would be set to null.

Thanks,
Joe






On Nov 27, 2009, at 10:38 AM, Michael Gentry wrote:

> Hi Joe,
> 
> I was just trying to figure out where the salesOrderList property was
> in your model, per this error:
> 
>    Error unsetting to-many DataObject property: salesOrderList
> 
> I can't tell if that is in SalesOrder or OrderItem and it doesn't seem
> to match salesOrder.getOrderItemList().
> 
> Thanks,
> 
> mrg
> 
> 
> On Fri, Nov 27, 2009 at 10:29 AM, Joe Baldwin  wrote:
>> Michael,
>> 
>> 
>>> Is childList the same as salesOrderList?
>> 
>> Sorry, I am not sure what you mean by "the same".
>> 
>> If you are asking is the entity self-referential, then the answer is no.  The parent
is named "SalesOrder" and the child is "OrderItem". It is a simple "to-many" relationship
(one sales-order to many order-items).
>> 
>> More info:
>> I did some more testing and found that the problem is associated with older SalesOrders
stored in the production server and seems to be creating an Exception on
>> 
>>        objectContext.deleteObjects(salesOrder.getOrderItemList())
>> 
>> However, when I create a SalesOrder with new data, I cannot duplicate the Exception
condition. So perhaps the Exception is somehow associated with the older data.
>> 
>> Also, I wrote my own "deleteObjects" method (for debugging purposes) and it appears
to work fine with the new SalesOrders or seemingly as well the ObjectContext version and generated
the same Exception with the older data.
>> 
>> The complication with debugging this issue is that the data is on the production
server and once I attempt a test (even though it claims that it failed) the data is actually
deleted, so I can't duplicate the test once all the data is deleted.
>> 
>> Thanks,
>> Joe
>> 
>> 
>> 
>> On Nov 27, 2009, at 10:03 AM, Michael Gentry wrote:
>> 
>>> Is childList the same as salesOrderList?
>>> 
>>> 
>>> On Thu, Nov 26, 2009 at 6:29 PM, Joe Baldwin 
wrote:
>>>> I am getting an odd exception when I attempt to delete a DataObject with
a "to-many" (aka child list).
>>>> 
>>>> Here is the pseudo code:
>>>> 
>>>> 1. deleteObjects(parent.getChildList())
>>>> 2. deleteObject(parent)
>>>> 3. objectContext.commitChanges()
>>>> 
>>>> on Exception
>>>>        objectcontext.rollbackChanges()
>>>> 
>>>> 
>>>> It is very odd but I am getting the following error:
>>>> 
>>>> org.apache.cayenne.reflect.PropertyException:
>>>> [v.3.0B1 Nov 03 2009 19:16:06]
>>>> Error unsetting to-many DataObject property: salesOrderList
>>>> 
>>>> But it is deleting all the associated database rows.
>>>> 
>>>> Am I missing a step in the delete procedure?
>>>> 
>>>> thanks,
>>>> Joe
>>>> 
>>>> 
>> 
>>

Re: Exception Deleting DataObject with to-many relationship

2009-11-27T15:38:51Z

Hi Joe,

I was just trying to figure out where the salesOrderList property was
in your model, per this error:

    Error unsetting to-many DataObject property: salesOrderList

I can't tell if that is in SalesOrder or OrderItem and it doesn't seem
to match salesOrder.getOrderItemList().

Thanks,

mrg


On Fri, Nov 27, 2009 at 10:29 AM, Joe Baldwin  wrote:
> Michael,
>
>
>> Is childList the same as salesOrderList?
>
> Sorry, I am not sure what you mean by "the same".
>
> If you are asking is the entity self-referential, then the answer is no. �The parent
is named "SalesOrder" and the child is "OrderItem". It is a simple "to-many" relationship
(one sales-order to many order-items).
>
> More info:
> I did some more testing and found that the problem is associated with older SalesOrders
stored in the production server and seems to be creating an Exception on
>
> � � � �objectContext.deleteObjects(salesOrder.getOrderItemList())
>
> However, when I create a SalesOrder with new data, I cannot duplicate the Exception condition.
So perhaps the Exception is somehow associated with the older data.
>
> Also, I wrote my own "deleteObjects" method (for debugging purposes) and it appears to
work fine with the new SalesOrders or seemingly as well the ObjectContext version and generated
the same Exception with the older data.
>
> The complication with debugging this issue is that the data is on the production server
and once I attempt a test (even though it claims that it failed) the data is actually deleted,
so I can't duplicate the test once all the data is deleted.
>
> Thanks,
> Joe
>
>
>
> On Nov 27, 2009, at 10:03 AM, Michael Gentry wrote:
>
>> Is childList the same as salesOrderList?
>>
>>
>> On Thu, Nov 26, 2009 at 6:29 PM, Joe Baldwin  wrote:
>>> I am getting an odd exception when I attempt to delete a DataObject with a "to-many"
(aka child list).
>>>
>>> Here is the pseudo code:
>>>
>>> 1. deleteObjects(parent.getChildList())
>>> 2. deleteObject(parent)
>>> 3. objectContext.commitChanges()
>>>
>>> on Exception
>>> � � � �objectcontext.rollbackChanges()
>>>
>>>
>>> It is very odd but I am getting the following error:
>>>
>>> org.apache.cayenne.reflect.PropertyException:
>>> [v.3.0B1 Nov 03 2009 19:16:06]
>>> Error unsetting to-many DataObject property: salesOrderList
>>>
>>> But it is deleting all the associated database rows.
>>>
>>> Am I missing a step in the delete procedure?
>>>
>>> thanks,
>>> Joe
>>>
>>>
>
>

Re: Exception Deleting DataObject with to-many relationship

2009-11-27T15:29:59Z

Michael,

> Is childList the same as salesOrderList?

Sorry, I am not sure what you mean by "the same".

If you are asking is the entity self-referential, then the answer is no.  The parent is named
"SalesOrder" and the child is "OrderItem". It is a simple "to-many" relationship (one sales-order
to many order-items).

More info:
I did some more testing and found that the problem is associated with older SalesOrders stored
in the production server and seems to be creating an Exception on

	objectContext.deleteObjects(salesOrder.getOrderItemList())

However, when I create a SalesOrder with new data, I cannot duplicate the Exception condition.
So perhaps the Exception is somehow associated with the older data.

Also, I wrote my own "deleteObjects" method (for debugging purposes) and it appears to work
fine with the new SalesOrders or seemingly as well the ObjectContext version and generated
the same Exception with the older data.

The complication with debugging this issue is that the data is on the production server and
once I attempt a test (even though it claims that it failed) the data is actually deleted,
so I can't duplicate the test once all the data is deleted.

Thanks,
Joe

On Nov 27, 2009, at 10:03 AM, Michael Gentry wrote:

> Is childList the same as salesOrderList?
> 
> 
> On Thu, Nov 26, 2009 at 6:29 PM, Joe Baldwin  wrote:
>> I am getting an odd exception when I attempt to delete a DataObject with a "to-many"
(aka child list).
>> 
>> Here is the pseudo code:
>> 
>> 1. deleteObjects(parent.getChildList())
>> 2. deleteObject(parent)
>> 3. objectContext.commitChanges()
>> 
>> on Exception
>>        objectcontext.rollbackChanges()
>> 
>> 
>> It is very odd but I am getting the following error:
>> 
>> org.apache.cayenne.reflect.PropertyException:
>> [v.3.0B1 Nov 03 2009 19:16:06]
>> Error unsetting to-many DataObject property: salesOrderList
>> 
>> But it is deleting all the associated database rows.
>> 
>> Am I missing a step in the delete procedure?
>> 
>> thanks,
>> Joe
>> 
>>

Re: Exception Deleting DataObject with to-many relationship

2009-11-27T15:03:32Z

Is childList the same as salesOrderList?


On Thu, Nov 26, 2009 at 6:29 PM, Joe Baldwin  wrote:
> I am getting an odd exception when I attempt to delete a DataObject with a "to-many"
(aka child list).
>
> Here is the pseudo code:
>
> 1. deleteObjects(parent.getChildList())
> 2. deleteObject(parent)
> 3. objectContext.commitChanges()
>
> on Exception
> � � � �objectcontext.rollbackChanges()
>
>
> It is very odd but I am getting the following error:
>
> org.apache.cayenne.reflect.PropertyException:
> [v.3.0B1 Nov 03 2009 19:16:06]
> Error unsetting to-many DataObject property: salesOrderList
>
> But it is deleting all the associated database rows.
>
> Am I missing a step in the delete procedure?
>
> thanks,
> Joe
>
>

Re: delete new --> transient?

2009-11-27T15:01:15Z

On Thu, Nov 26, 2009 at 12:52 PM, Lachlan Deck  wrote:
> On 27/11/2009, at 2:24 AM, Andrey Razumovsky wrote:
>
>> Because for deleted objects DELETE query will be forced, and if you create
>> (register), then delete (unregister) an object it looks like as if it was
>> never registered in context.
>
> This seems (to me, at least) to be implementation details of the framework that's overly
exposed to general users ('cause you have to know the implementation details in order to make
any use of those persistence states in any meaningful way.... e.g., what does transient mean?
Well it depends.... What does deleted mean? Again it depends on other conditions.). Perhaps
then PersistenceState should be private to the framework.

Sometimes application code needs access to this and making it private
wouldn't help that matter.

> But this still means that there's no 'general purpose' method that I'm aware of (e.g.,
in Cayenne 'the new static helper' ... ah, see, if you'd called it CayenneUtils or PersistentUtils
there'd be no need for further clarification of what Cayenne refers to via email ;-) �which
answers the basic question: 'is this object marked for deletion (regardless of whether it
was previously persisted)?'

Well, an object should only be marked for deletion if it needs to be
deleted (it exists in the DB).  So Cayenne is working properly in this
regard.  If an object has never been persisted (does NOT exist in the
DB), then it is marked as transient if you delete it.

> I simply want to know if an object is marked for deletion within the context. It should
be simple like the question itself. :) � �And to answer the question, because I need to know
at a later point whether to replace the object with a new one.

By context I assume you mean data/object context.  My previous comment
still applies.  :-)  The DataContext needs to know what to do when you
commitChanges().  If an object's persistence state is set to DELETED,
then the DC knows it needs to issue a DELETE to the DB on
commitChanges() (TRANSIENT objects will not be persisted).  The
JavaDoc even specifies this:

    /**
     * Describes a state of an object registered with
DataContext/ObjectContext, that will
     * be deleted from the database on the next commit.
     */
    public static final int DELETED = 6;

Here is TRANSIENT:

    /**
     * Describes a state of an object not registered with
DataContext/ObjectContext, and
     * therefore having no persistence features.
     */
    public static final int TRANSIENT = 1;

If you register an object with a DC and then delete it (without ever
persisting it), then it becomes TRANSIENT.  If you register an object
with a DC, commit it, then delete it, it becomes DELETED.  Keep in
mind the DC exists to manage your objects for committing changes to
the DB, not to track general Java usage (such as removing an object
from a collection).

mrg

Exception Deleting DataObject with to-many relationship

2009-11-26T23:29:08Z

I am getting an odd exception when I attempt to delete a DataObject with a "to-many" (aka child
list).

Here is the pseudo code:

1. deleteObjects(parent.getChildList())
2. deleteObject(parent)
3. objectContext.commitChanges()

on Exception
	objectcontext.rollbackChanges()


It is very odd but I am getting the following error:

org.apache.cayenne.reflect.PropertyException: 
[v.3.0B1 Nov 03 2009 19:16:06]
Error unsetting to-many DataObject property: salesOrderList

But it is deleting all the associated database rows.

Am I missing a step in the delete procedure?

thanks,
Joe

Re: delete new --> transient?

2009-11-26T17:52:34Z

On 27/11/2009, at 2:24 AM, Andrey Razumovsky wrote:

> Because for deleted objects DELETE query will be forced, and if you create
> (register), then delete (unregister) an object it looks like as if it was
> never registered in context.

This seems (to me, at least) to be implementation details of the framework that's overly exposed
to general users ('cause you have to know the implementation details in order to make any
use of those persistence states in any meaningful way.... e.g., what does transient mean?
Well it depends.... What does deleted mean? Again it depends on other conditions.). Perhaps
then PersistenceState should be private to the framework.

But this still means that there's no 'general purpose' method that I'm aware of (e.g., in
Cayenne 'the new static helper' ... ah, see, if you'd called it CayenneUtils or PersistentUtils
there'd be no need for further clarification of what Cayenne refers to via email ;-)  which
answers the basic question: 'is this object marked for deletion (regardless of whether it
was previously persisted)?'

> Why you need such testing?

I simply want to know if an object is marked for deletion within the context. It should be
simple like the question itself. :)    And to answer the question, because I need to know
at a later point whether to replace the object with a new one.

i.e., there's basic questions that are generally useful:
isNew, isModified, isDeleted.

> Currently I can think only of quite nasty
> workaround on ROP 3.0 - using custom contexts and overriding deleteObject()

I ended up having to do:
public boolean isDeleted() {
	return
	getObjectContext() == null
	|| getObjectContext().deletedObjects().contains(this)
	|| !getObjectContext().getGraphManager().registeredNodes().contains(getRecord());
}

It's a bit unintuitive imho for deletedObjects to not contain these things ... for surely
they could be dealt with (i.e., treated as unregistered) during the saveChanges operations
should an object be both new and deleted(?)....

> 2009/11/26 Lachlan Deck 
> 
>> Hi there,
>> 
>> just wondering why when deleting a new object that its status is being set
>> to PeristenceState.TRANSIENT rather than DELETED?
>> 
>> @see ObjectContextDeleteAction#deleteNew(Persistent)
>> It also doesn't turn up in context.deletedObjects
>> 
>> So this all seems to make it more difficult to determine the state of an
>> object.
>> 
>> Regardless of the rationale - what's the recommended way of determining if
>> an object is deleted within the context?
>> Thanks.
>> 
>> with regards,
>> --
>> 
>> Lachlan Deck
>> 
>> 
> 
> 
> -- 
> Andrey

with regards,
--

Lachlan Deck

Re: delete new --> transient?

2009-11-26T15:24:29Z

Because for deleted objects DELETE query will be forced, and if you create
(register), then delete (unregister) an object it looks like as if it was
never registered in context.
Why you need such testing? Currently I can think only of quite nasty
workaround on ROP 3.0 - using custom contexts and overriding deleteObject()

2009/11/26 Lachlan Deck 

> Hi there,
>
> just wondering why when deleting a new object that its status is being set
> to PeristenceState.TRANSIENT rather than DELETED?
>
> @see ObjectContextDeleteAction#deleteNew(Persistent)
> It also doesn't turn up in context.deletedObjects
>
> So this all seems to make it more difficult to determine the state of an
> object.
>
> Regardless of the rationale - what's the recommended way of determining if
> an object is deleted within the context?
> Thanks.
>
> with regards,
> --
>
> Lachlan Deck
>
>


-- 
Andrey

delete new --> transient?

2009-11-26T01:33:09Z

Hi there,

just wondering why when deleting a new object that its status is being set to PeristenceState.TRANSIENT
rather than DELETED?

@see ObjectContextDeleteAction#deleteNew(Persistent)
It also doesn't turn up in context.deletedObjects

So this all seems to make it more difficult to determine the state of an object.

Regardless of the rationale - what's the recommended way of determining if an object is deleted
within the context?
Thanks.

with regards,
--

Lachlan Deck

Re: Temporary ID hasn't been replaced on commit

2009-11-25T13:53:46Z

On Wed, Nov 25, 2009 at 8:47 AM, Juergen Saar  wrote:
> For using 3.0 in productive environment ... Is there a time-scale for the
> final 3.0?

There isn't a final date, but hope to have it out soon.  However, I
don't think you should let the beta label stop you.  I'm using 3.0B1
in something I plan to deploy in production (was using 3.0M6 prior to
that) and Borut just posted to the list about a large-scale effort in
which he used 3.0 (not sure which tag) to deploy to production.  There
might be a few issues lurking, but it seems pretty stable overall and
we are looking for feedback from the user community to iron out any
remaining issues and release the final version.

Thanks,

mrg

Re: Temporary ID hasn't been replaced on commit

2009-11-25T13:53:24Z

As you probably know, we are already in Beta and Cayenne runtime  
framework code is frozen. So it is 100% stable from the API  
perspective. And after 1 or 2 intermediate releases it becomes final.  
Timewise, I don't know, maybe a couple of months?

Andrus

On Nov 25, 2009, at 3:47 PM, Juergen Saar wrote:

> I'm in preparations for 3.0 ... but there was a lot of trouble this  
> year, so
> I didn't get as far as I planned ...
>
> For using 3.0 in productive environment ... Is there a time-scale  
> for the
> final 3.0?
>
>
> 2009/11/25 Andrus Adamchik 
>
>> Do you have an option of trying this with 3.0? There were a few bug  
>> fixes
>> related to unstable data types in ObjectIds (e.g. the same ID can  
>> have a PK
>> mapping as a BigDecimal or Integer depending on how object was  
>> obtained).
>> Could be something related.
>>
>> Andrus
>>
>>
>>
>> On Nov 25, 2009, at 10:32 AM, Juergen Saar wrote:
>>
>> I'm using Version 2.0.4 ...
>>>
>>> 2009/11/25 Andrus Adamchik 
>>>
>>> Don't yet know what might be causing it, but what version of  
>>> Cayenne are
>>>> you using?
>>>>
>>>> Andrus
>>>>
>>>>
>>>> On Nov 25, 2009, at 9:49 AM, Juergen Saar wrote:
>>>>
>>>> Hi,
>>>>
>>>>>
>>>>> we're using cayenne for the web-interface of a 20 year old  
>>>>> project with
>>>>> meaningful keys. We don't use tapestry. The keys are handled in  
>>>>> the
>>>>> validateForSave().
>>>>>
>>>>> In some cases after commit there is an Exception: "Temporary ID  
>>>>> hasn't
>>>>> been
>>>>> replaced on commit"
>>>>> The values of the Dataobject are OK and the Informations put to  
>>>>> database
>>>>> are
>>>>> correct.
>>>>>
>>>>> In the Objects that cause this Exception I can't see any  
>>>>> difference to
>>>>> Objects that don't cause this Execption.
>>>>>
>>>>> Is there anything I can do to force the replacement if the Temp  
>>>>> ID or to
>>>>> prevent this Exception?
>>>>>
>>>>> Caching in cayenne is disabled, because there are many other
>>>>> applications
>>>>> also manipulating data in database.
>>>>>
>>>>>
>>>>> Any hint would help ...
>>>>> -Juergen-
>>>>>
>>>>>
>>>>
>>>>
>>

Re: Temporary ID hasn't been replaced on commit

2009-11-25T13:47:20Z

I'm in preparations for 3.0 ... but there was a lot of trouble this year, so
I didn't get as far as I planned ...

For using 3.0 in productive environment ... Is there a time-scale for the
final 3.0?


2009/11/25 Andrus Adamchik 

> Do you have an option of trying this with 3.0? There were a few bug fixes
> related to unstable data types in ObjectIds (e.g. the same ID can have a PK
> mapping as a BigDecimal or Integer depending on how object was obtained).
> Could be something related.
>
> Andrus
>
>
>
> On Nov 25, 2009, at 10:32 AM, Juergen Saar wrote:
>
>  I'm using Version 2.0.4 ...
>>
>> 2009/11/25 Andrus Adamchik 
>>
>>  Don't yet know what might be causing it, but what version of Cayenne are
>>> you using?
>>>
>>> Andrus
>>>
>>>
>>> On Nov 25, 2009, at 9:49 AM, Juergen Saar wrote:
>>>
>>> Hi,
>>>
>>>>
>>>> we're using cayenne for the web-interface of a 20 year old project with
>>>> meaningful keys. We don't use tapestry. The keys are handled in the
>>>> validateForSave().
>>>>
>>>> In some cases after commit there is an Exception: "Temporary ID hasn't
>>>> been
>>>> replaced on commit"
>>>> The values of the Dataobject are OK and the Informations put to database
>>>> are
>>>> correct.
>>>>
>>>> In the Objects that cause this Exception I can't see any difference to
>>>> Objects that don't cause this Execption.
>>>>
>>>> Is there anything I can do to force the replacement if the Temp ID or to
>>>> prevent this Exception?
>>>>
>>>> Caching in cayenne is disabled, because there are many other
>>>> applications
>>>> also manipulating data in database.
>>>>
>>>>
>>>> Any hint would help ...
>>>> -Juergen-
>>>>
>>>>
>>>
>>>
>

Re: Temporary ID hasn't been replaced on commit

2009-11-25T13:27:43Z

Do you have an option of trying this with 3.0? There were a few bug  
fixes related to unstable data types in ObjectIds (e.g. the same ID  
can have a PK mapping as a BigDecimal or Integer depending on how  
object was obtained). Could be something related.

Andrus


On Nov 25, 2009, at 10:32 AM, Juergen Saar wrote:

> I'm using Version 2.0.4 ...
>
> 2009/11/25 Andrus Adamchik 
>
>> Don't yet know what might be causing it, but what version of  
>> Cayenne are
>> you using?
>>
>> Andrus
>>
>>
>> On Nov 25, 2009, at 9:49 AM, Juergen Saar wrote:
>>
>> Hi,
>>>
>>> we're using cayenne for the web-interface of a 20 year old project  
>>> with
>>> meaningful keys. We don't use tapestry. The keys are handled in the
>>> validateForSave().
>>>
>>> In some cases after commit there is an Exception: "Temporary ID  
>>> hasn't
>>> been
>>> replaced on commit"
>>> The values of the Dataobject are OK and the Informations put to  
>>> database
>>> are
>>> correct.
>>>
>>> In the Objects that cause this Exception I can't see any  
>>> difference to
>>> Objects that don't cause this Execption.
>>>
>>> Is there anything I can do to force the replacement if the Temp ID  
>>> or to
>>> prevent this Exception?
>>>
>>> Caching in cayenne is disabled, because there are many other  
>>> applications
>>> also manipulating data in database.
>>>
>>>
>>> Any hint would help ...
>>> -Juergen-
>>>
>>
>>

Re: Temporary ID hasn't been replaced on commit

2009-11-25T08:32:21Z

I'm using Version 2.0.4 ...

2009/11/25 Andrus Adamchik 

> Don't yet know what might be causing it, but what version of Cayenne are
> you using?
>
> Andrus
>
>
> On Nov 25, 2009, at 9:49 AM, Juergen Saar wrote:
>
>  Hi,
>>
>> we're using cayenne for the web-interface of a 20 year old project with
>> meaningful keys. We don't use tapestry. The keys are handled in the
>> validateForSave().
>>
>> In some cases after commit there is an Exception: "Temporary ID hasn't
>> been
>> replaced on commit"
>> The values of the Dataobject are OK and the Informations put to database
>> are
>> correct.
>>
>> In the Objects that cause this Exception I can't see any difference to
>> Objects that don't cause this Execption.
>>
>> Is there anything I can do to force the replacement if the Temp ID or to
>> prevent this Exception?
>>
>> Caching in cayenne is disabled, because there are many other applications
>> also manipulating data in database.
>>
>>
>> Any hint would help ...
>> -Juergen-
>>
>
>

Re: [ANNOUNCEMENT] Success story

2009-11-25T08:12:02Z

Also we can update the page [1] with your words

[1] http://cayenne.apache.org/success-stories.html

2009/11/25 Borut Bolčina 

> Hello,
>
> I would like to share a Cayenne success story on this list. Four days ago
> we
> launched a renewed site www.najdi.si. It is a search engine site in
> Slovenia
> with over 600.000 visits per day (on the launch day this figure was well
> over million). Users now have the option to register and log in to have the
> benefit of customizing the site with a set of widgets available from the
> library. Over 110.000 registered users at this moment.
>
> The site is in a cluster and the architecture is moving towards REST
> interfaces. The Cayenne is used at almost all levels - getting the data for
> widgets from external resources and later to pump this data to frontend.
>
> All in all it was a good experience and I can only confirm the framework is
> mature enough (3.0) to handle big projects. What I was missing from the
> documentation was good usage patterns, anti patterns and cookbook examples
> for variety of problems. Well, there are no problems, only challenges :-)
>
> Thanks to the Cayenne team for all the effort in developing this framework!
>
> Regards,
> Borut
>
> P.S. My only wish now is that Robert and Kevin (others?) will continue to
> work on the Cayenne-Tapestry5 integration!!!
>



-- 
Andrey

Re: Temporary ID hasn't been replaced on commit

2009-11-25T07:51:34Z

Don't yet know what might be causing it, but what version of Cayenne  
are you using?

Andrus

On Nov 25, 2009, at 9:49 AM, Juergen Saar wrote:

> Hi,
>
> we're using cayenne for the web-interface of a 20 year old project  
> with
> meaningful keys. We don't use tapestry. The keys are handled in the
> validateForSave().
>
> In some cases after commit there is an Exception: "Temporary ID  
> hasn't been
> replaced on commit"
> The values of the Dataobject are OK and the Informations put to  
> database are
> correct.
>
> In the Objects that cause this Exception I can't see any difference to
> Objects that don't cause this Execption.
>
> Is there anything I can do to force the replacement if the Temp ID  
> or to
> prevent this Exception?
>
> Caching in cayenne is disabled, because there are many other  
> applications
> also manipulating data in database.
>
>
> Any hint would help ...
> -Juergen-