cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: ColumnSelect API + Persistent objects
Date Mon, 13 Mar 2017 08:26:53 GMT
> Oh, I get it now. You are suggesting in option (2) that Cayenne creates a CROSS JOIN in
sql.

Actually not a CROSS join. It will be a regular INNER JOIN based on relationship from the
query root. JPA spec defines CROSS join operations. We don't (yet?).

> Sometimes you want to fetch specific columns as read-only for performance reasons. I
get that. You save on fetching data and you save time on constructing full ObjEntities.


Yep. A typical use case for intermixing DataObjects and scalars in the result is this: [<artist>,
<count_of_paintings>] that gives us each object's to-many counts without resolving to-many
relationships. What I am unsure though is whether [<artist_name>, <painting>]
result is of any use to anyone.

> Are users going to be confused that the ObjEntities are bound to a context and editable/committable,
but the raw columns are not?

I am not concerned about this. I think everyone should understand that only DataObjects can
be committed. Any other representations is non-updateable data.

Andrus


> On Mar 13, 2017, at 10:29 AM, Aristedes Maniatis <ari@maniatis.org> wrote:
> 
> On 13/3/17 5:57pm, Andrus Adamchik wrote:
>> 
>>>>> 
>>>>> List<Object[]> result = ObjectSelect.query(Artist.class)
>>>>>      .columns(Artist.ARTIST_NAME, Artist.PAINTING_ARRAY)
>>>>>      .select(context);
>> 
>> 
>>>> For me it's not clear when do we need direct List result for toMany
>>>> relationship instead of using Prefetch (or even selecting related
>>>> entities explicitly).
>> 
>> Let's ponder on this some more. In the example above there are two possible result
mappings of to-many - each cell at index 1 can store either (1) a List<Painting> or
(2) a Painting. Of course in the second case Artist name at index 0 will be repeated for each
painting of a given Artist (so the result is flattened). 
>> 
>> In the proposed solution we throw in the first case and support the second. I'd like
to hear opinions on the usefulness of either of the cases, and maybe some real life examples.
> 
> 
> Oh, I get it now. You are suggesting in option (2) that Cayenne creates a CROSS JOIN
in sql.
> 
> Surely most of the time we are steering users to creating ObjEntities where possible;
then they have the full access to follow relations, prefetching, pagination, etc, etc.
> 
> Sometimes you want to fetch specific columns as read-only for performance reasons. I
get that. You save on fetching data and you save time on constructing full ObjEntities. But
then why would you want to embed full ObjEntities in the result? Any performance benefits
are surely out the window. So what's the point and the use-case?
> 
> 
> 
> Are users going to be confused that the ObjEntities are bound to a context and editable/committable,
but the raw columns are not?
> 
> result.get(0)[3][1].setName("The scream")
> result.get(0)[2] = "Munch"
> context.commit()
> 
> 
> 
> What is the output of this:
> 
> result = ObjectSelect.query(Artist.class)
>       .columns(createSelf(Artist.class))
>       .select(context);
> 
> Is that the same as 
> 
> result = ObjectSelect.query(Artist.class)
>       .select(context);
> 
> would the generated SQL be the same?
> 
> Ari
> 
> 
> 
> 
> -- 
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A


Mime
View raw message