On Tue, Jan 10, 2017 at 5:27 AM, Aristedes Maniatis wrote:
> On 9/1/17 8:45pm, Nikita Timofeev wrote:
>>> Could that syntax above could be cleaner like:
>>>
>>>Property nameLength =
>>> Artist.ARTIST_NAME.function(Expression.SQL_LENGTH)
>>>
>>> or is that just going to result in a whole lot o
On Tue, Jan 10, 2017 at 5:45 AM, Aristedes Maniatis wrote:
> On 9/1/17 8:45pm, Nikita Timofeev wrote:
>> But your feedback is pushing me towards the solution that I didn't
>> want to use initially:
>> to introduce some abstract FluentSelect with descendants like
>> ObjectSelect and ColumnSelect.
>
On 9/1/17 8:45pm, Nikita Timofeev wrote:
> But your feedback is pushing me towards the solution that I didn't
> want to use initially:
> to introduce some abstract FluentSelect with descendants like
> ObjectSelect and ColumnSelect.
> Where ColumnSelect can be used directly or can be created within
On 9/1/17 8:45pm, Nikita Timofeev wrote:
>> Could that syntax above could be cleaner like:
>>
>>Property nameLength =
>> Artist.ARTIST_NAME.function(Expression.SQL_LENGTH)
>>
>> or is that just going to result in a whole lot of clutter in the class?
>>
> Such methods will create too much coupl
On 9/1/17 8:45pm, Nikita Timofeev wrote:
> ObjectSelect.query(Artist.class)
> .columns(Artist.ARTIST_NAME, artistCount)
> .having(Artist.ARTIST_NAME.like("a%"))
> .or(artistCount.gt(2L)) // this goes to having
> .select(context)
You are right. Since you can combine where() clau
> On Jan 9, 2017, at 4:45 AM, Nikita Timofeev wrote:
>
>>
>> Finally, 'having()' matches the SQL (HAVING is needed for queries on the
>> result of functions). Have you thought about how that could be abstracted
>> away so that the user can use where() and the correct SQL is still generated
>
On Sun, Jan 8, 2017 at 3:26 PM, Aristedes Maniatis wrote:
> On 8/1/17 1:03am, Nikita Timofeev wrote:
>
>> The later is closer to the design.
>> Both column() and columns() methods return same ObjectSelect object,
>> they only change result type (as fetchDataRows() method do):
>> column() changes r
On 8/1/17 1:03am, Nikita Timofeev wrote:
> The later is closer to the design.
> Both column() and columns() methods return same ObjectSelect object,
> they only change result type (as fetchDataRows() method do):
> column() changes result to ObjectSelect, where T is type of
> Property, so no cast o
> On Jan 7, 2017, at 5:03 PM, Nikita Timofeev wrote:
>
>>
>> would a map be more useful to return than this tuple style approach? Java's
>> collections are a bit clunky, but:
>>
>>
>> Map result2 = ObjectSelect.query(Artist.class)
>>.columns(Artist.ARTIST_NAME, paintingCountP
Hi Ari
Thank you for your so detailed feedback!
I'll try to explain a little bit our new design. (By the way you can
already try some parts of it: string and math functional expressions
and column() / columns() methods)
> The problem here is that selectOne no longer returns . This
> seems like
On 7/1/17 12:08am, Nikita Timofeev wrote:
> Hi all,
>
> I would like to present new Cayenne feature in development to you: API
> for SQL functions (both aggregate and non aggregate).
>
> When it will be completed it will be possible to use functions in
> select queries with pure API calls without
This is really nice and something that we wanted to have in Cayenne for years!
It plugs a huge hole in the query capabilities and will be a major 4.0 feature.
I am looking forward to upgrading a few of my projects and rewriting a bunch of
queries using the new API.
Andrus
> On Jan 6, 2017, at
Hi all,
I would like to present new Cayenne feature in development to you: API
for SQL functions (both aggregate and non aggregate).
When it will be completed it will be possible to use functions in
select queries with pure API calls without writing any custom SQL or
EJBQL queries.
You'll be able
13 matches
Mail list logo
