Here is latest version that already committed and can be tested:
ObjectSelect
.columnQuery(Artist.class,
Property.createSelf(Artist.class),
// query root
Artist.PAINTING_ARRAY.dot(Painting.GALLERY), // toOne relationship
Artist.PAINTING_ARRAY.flat(Painting.class)) //
flattened toMany relationship
.select(context);
On Thu, Mar 16, 2017 at 11:48 AM, Andrus Adamchik
<[email protected]> wrote:
>
>
>> On Mar 16, 2017, at 11:14 AM, Nikita Timofeev <[email protected]>
>> wrote:
>>
>> On Mon, Mar 13, 2017 at 3:05 PM, Aristedes Maniatis <[email protected]>
>> wrote:
>>> On 13/3/17 9:53pm, Andrus Adamchik wrote:
>>>>
>>>>> On Mar 13, 2017, at 1:46 PM, Aristedes Maniatis <[email protected]> wrote:
>>>>>
>>>>>
>>>>> Just a wild thought, but would this syntax be helpful...
>>>>>
>>>>> List<Object[]> result = ObjectSelect.query(Artist.class)
>>>>> .addColumns(Artist.PAINTING_COUNT)
>>>>> .select(context);
>>>>>
>>>>> So then we are adding more columns to the existing DataObject query
>>>>> rather than having to define the DataObjects as properties in themselves.
>>>>> The syntax above might be simpler to understand and write.
>>>>
>>>> So "addColumns" vs "columns"? IIRC we tried something similar with
>>>> orderings (override all orderings vs add to the existing orderings), and
>>>> that confused everybody (including me as the author), so that was undone
>>>> between the milestones.
>>>
>>>
>>> Except in this case it is very different result since with this syntax you
>>> get the mixed columns/DataObject results and avoid needing to create
>>> properties for 'self' or some other confusing construct.
>>>
>>
>> I think we can add Property<EntityType> SELF to default cgen
>> templates, then everything will be pretty simple:
>>
>> ObjectSelect
>> .columnQuery(Artist.class, Artist.SELF, Artist.PAINTING_ARRAY.count())
>> .select(context);
>>
>
> A good idea except for a possible naming conflict if a Java object has a
> persistent property called "self".
>
> Andrus
--
Best regards,
Nikita Timofeev
