Exactly. The idea is to have a single query combining the capabilities
of SelectQuery and EJBQLQuery, with API allowing to build it in the
code (as well as keeping the String representation as an option).
Andrus
On Apr 27, 2010, at 5:51 PM, Andrew Lindesay wrote:
Hello Andrus;
...unfortun
Hello Andrus;
> ...unfortunate situation, as there are plans for SelectQuery-like API for
> EJBQL in 3.1, but...
I just want to check on this one; you are planning to expose an "object
interface" to the EJBQL in 3.1 such that arbitrary EJBSQL queries could be
assembled in-code as opposed to th
Done.
On Apr 26, 2010, at 8:11 PM, Andrew Lindesay wrote:
Hi Andrus;
I think this would be really great until a formal means of
configuring the property-paths to retrieve as "data rows" is
publically-available; are you able to apply that to STABLE-3.0 for me?
cheers.
I won't oppose this
Hi Andrus;
I think this would be really great until a formal means of configuring the
property-paths to retrieve as "data rows" is publically-available; are you able
to apply that to STABLE-3.0 for me?
cheers.
> I won't oppose this particular change, as long as you realize the risk of
> relyi
I won't oppose this particular change, as long as you realize the risk
of relying on this semi-private API.
Andrus
On Apr 26, 2010, at 5:40 PM, Andrew Lindesay wrote:
Hi Andrus;
Would it be possible to make the method;
SelectTranslator.buildResultColumns()
...protected so that I
Hi Andrus;
Would it be possible to make the method;
SelectTranslator.buildResultColumns()
...protected so that I could potentially try to override it, pull the SQL out
and run it manually to get the primary keys?
cheers.
> Currently none of the resolved objects will be turned into fau
Currently none of the resolved objects will be turned into faults. We
discussed swapping out pages, using some algorithm (e.g. LRU). It was
decided that we can't predict in all cases what to swap out, so that
was put on hold. I think we even have a Jira for it somewhere. Not
supported at th
Hi Ari;
Another question on this; if I "page around the list" are the objects not in
the "current page" subject to garbage collection?
cheers.
>> Aha! (penny drops) -- ok that is the behaviour I'm after. Thanks to both of
>> you for talking this through. I've written some material to go at t
On 25/04/10 10:40 PM, Andrew Lindesay wrote:
Aha! (penny drops) -- ok that is the behaviour I'm after. Thanks to both of you for
talking this through. I've written some material to go at the top of
"SelectQuery" javadoc to confirm my understanding and augment the javadoc for
others;
I comm
Hi Ari;
Aha! (penny drops) -- ok that is the behaviour I'm after. Thanks to both of
you for talking this through. I've written some material to go at the top of
"SelectQuery" javadoc to confirm my understanding and augment the javadoc for
others;
Paginated Mode
By configuring an instance of
On 25/04/10 8:33 PM, Andrew Lindesay wrote:
In actual fact, I want to get the primary keys so that I can randomly
page-through a list of ObjectId-s faulting a page at a time.
Are you perhaps misunderstanding the way pagination works or am I missing what
you want to do? When you get a paginate
Hello Andrus;
> Not impossible, but is indeed rather involved and I don't see much point
> doing it.
I worked through SelectTranslator.appendQueryColumns(..) and I assume this
method would require quite a bit of re-hashing -- yes; looks like hard work to
change!
In actual fact, I want to get
On Apr 25, 2010, at 5:17 PM, Andrew Lindesay wrote:
Hi Andrus;
I would rather not have free-form query strings in my code; I
prefer compiling against the Cayenne query-assembly objects.
Yeah, that's a somewhat unfortunate situation, as there are plans
for SelectQuery-like API for EJBQL in
Hi Andrus;
>> I would rather not have free-form query strings in my code; I prefer
>> compiling against the Cayenne query-assembly objects.
> Yeah, that's a somewhat unfortunate situation, as there are plans for
> SelectQuery-like API for EJBQL in 3.1, but the old API for specifying columns
> i
On Apr 25, 2010, at 5:07 PM, Andrew Lindesay wrote:
I would rather not have free-form query strings in my code; I prefer
compiling against the Cayenne query-assembly objects.
Yeah, that's a somewhat unfortunate situation, as there are plans for
SelectQuery-like API for EJBQL in 3.1, but th
Hi Andrus;
Thanks for the speedy response.
I saw this facility in the 2.0 API.
I would rather not have free-form query strings in my code; I prefer compiling
against the Cayenne query-assembly objects.
Do you think this would be a tricky thing for me to safely implement in the
3.0-TRUNK?
che
We had this functionality prior to Cayenne 3.0. Now the recommended
way to specify columns is to use EJBQLQuery instead of SelectQuery. It
would return either a list of scalars or list of Object[], depending
on a number of columns in the query. E.g.:
"select a.artistName from Artist a"
And
Hello;
The "SelectQuery" has the method "setFetchingDataRows()" which I understand to
mean that the query will return a List.
I would also like to specify the attribute properties or similar which I would
like to be returned for the query –– is this possible with Cayenne?
For those who are als
18 matches
Mail list logo
