hi again!

We have a javascript query builder, where user can construct queries to our
fact/dimensional model. More than 50 possible data filters are sent to our
java backend. So we have this kind of code (of course, it´s a
simplification :-) ):


FilterEngine engine = new FilterEngine(request);

DSL.select(engine.getSelectFields())/* it's possible! :-) */
        .from(engine.getFactTable())/* it's possible! :-) */
        .joins(engine.getDimensionJoins())/* NOT possible :-( */
        .where(engine.getWhereConditions())/* it's possible! :-) */
        .groupBy(engine.getGroupByFields())/* it's possible! :-) */
        .orderBy(engine.getSortFields());/* it's possible! :-) */


Usually not all the query parts are mobile parts, but normally
dimension tables are joined if a filter is present in the incoming
json...

Thanks!!!



On Fri, Jul 15, 2016 at 6:28 PM, Lukas Eder <lukas.e...@gmail.com> wrote:

> Hi Luis,
>
> Hmm, interesting, thanks a lot for your suggestion. Hah, this is a very
> low level query builder API method. I somehow wish it didn't exist (in the
> public API) :)
>
> But I certainly see your use-case. Let's discuss!
>
> 1. What are the pain points when constructing complex joins through the
> "official" DSL API, i.e. by doing something like:
>
> Table<?> join = BASE_TABLE;
> if (something)
>     join = join.join(OTHER_TABLE).on(condition);
> if (somethingElse)
>     join = join...;
>
>
> 2. What's the use-case? Perhaps I'll better understand where this could
> go, if I know what exactly you understand by "complex query"
>
> Cheers,
> Lukas
>
> 2016-07-15 13:46 GMT+02:00 <luis.art...@buntplanet.com>:
>
>> Hi lukas!
>>
>> For really complex queries is really useful query.addJoin(BOOK,
>> JoinType.LEFT_OUTER_JOIN, BOOK.AUTHOR_ID.equal(AUTHOR.ID));
>>
>> I would love a way to add a list of joins... something like
>> query.addJoins(/* List<Tuple3<Table,Field,Condition>> */)
>>
>> is that possible? thanks!
>>
>>
>> On Friday, July 15, 2016 at 6:52:34 AM UTC+2, mi...@providencehr.com
>> wrote:
>>>
>>> Hi Lukas,
>>>
>>> A generated method to provide a type safe insert statement including all
>>> the table columns would be extremely useful for us. We typically use
>>> records to do inserts but for a few high volume processes we are batching
>>> raw inserts. We found this significantly faster than instantiating records
>>> and using dsl.batchInsert(). The issue with this is that as our schema
>>> evolves it's easy to leave columns out of the insert. So for instance if I
>>> have a table customer, it would be great to be able to do something like
>>>
>>> Tables.CUSTOMER.insert(name, street1, ...)
>>>
>>>
>>> On Thursday, July 14, 2016 at 12:47:59 PM UTC-5, Samir Faci wrote:
>>>>
>>>> Hi Lukas,
>>>>
>>>>
>>>> Sorry for the long delay in response.  We've used the JPA with default
>>>> mapper to load data into both Records and POJOs and having the ability to
>>>> go back and forth or even in one direction (Records -> Pojos) would be
>>>> great.
>>>>
>>>> Thanks for opening up the ticket.
>>>>
>>>> Our usual cases tends to be one of 3 scenarios.
>>>>
>>>> LoadInto:
>>>>   - Generated Records.class
>>>>   - Generated POJO .class
>>>>   - HandRolled POJO due to data being returned and modeled differently
>>>> then the DB.
>>>>
>>>> I would assume that 1 and 2 is somewhat doable. 3rd Item is probably
>>>> not feasible, but if there was some mechanism that would allows us to go
>>>> from any of these entities back and forth that'd be great.
>>>>
>>>> Even the HandRolled POJOs.  end of the day we end up with
>>>>
>>>> Object.fieldName  maps to GeneratedPojo.fieldName which corresponds to
>>>> GeneratedRecord.fieldName.
>>>>
>>>> having the ability to say take a List of hand rolled POJO and
>>>> extrapolate a List of records we can INSERT/UPDATE depending on use case
>>>> would be very useful to us.
>>>>
>>>> that being said, this is "our" needs, it doesn't necessarily make sense
>>>> for Jooq in general.  Just passing on our use case in case it resonates
>>>> with others and feedback was requested. :)
>>>>
>>>>
>>>> --
>>>> Samir
>>>>
>>>>
>>>>
>>>> On Tue, Jul 12, 2016 at 11:04 PM, Lukas Eder <lukas...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Samir,
>>>>>
>>>>> I have registered a feature request to generate a mapper() onto
>>>>> generated TableRecords:
>>>>> https://github.com/jOOQ/jOOQ/issues/5412
>>>>>
>>>>> That's a low hanging fruit. Additional features are certainly
>>>>> possible, but need more discussion, I think.
>>>>>
>>>>> Best Regards,
>>>>> Lukas
>>>>>
>>>>>
>>>>> 2016-07-07 10:35 GMT+02:00 Lukas Eder <lukas...@gmail.com>:
>>>>>
>>>>>> Hi Samir,
>>>>>>
>>>>>> 2016-07-07 4:50 GMT+02:00 Samir Faci <sa...@esamir.com>:
>>>>>>
>>>>>>> 1.  One conversion that would be useful to have is the ability to
>>>>>>> convert from POJOs to Records and vice versa.
>>>>>>>
>>>>>>> On occasion I need to roll out my own POJO because our data is
>>>>>>> represented different at the service layer then how the data
>>>>>>> is actually stored, but I find myself using the autogenerated
>>>>>>> records and POJOs a good bit.  It would be nice if there was an easy 
>>>>>>> way to
>>>>>>> going from say:
>>>>>>>
>>>>>>> TableNameRecord  -->  TableName (pojo) and back.
>>>>>>>
>>>>>>
>>>>>> Do I get you right, you'd like a hard-coded method in the generated
>>>>>> TableNameRecord that does the mapping for the generated POJO? E.g.
>>>>>>
>>>>>>
>>>>>> class TableNameRecord extends UpdatableRecordImpl {
>>>>>>     ...
>>>>>>     public TableNamePojo intoTableNamePojo() { ... }
>>>>>>     public void fromTableNamePojo(TableNamePojo pojo) { ... }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Would this really help? I can definitely see the into() method. The
>>>>>> from() method doesn't seem to add that much value over the existing
>>>>>> Record.from(Object) method, except, perhaps, some additional type safety?
>>>>>>
>>>>>>
>>>>>>> It varies on my use case but I tend to usually fetchInto(  . class)
>>>>>>> and most of the the class passed in is either the record or pojo that 
>>>>>>> was
>>>>>>> generated by jooq.
>>>>>>>
>>>>>>
>>>>>> Oh, I see, that's a different story, though. The problem is that
>>>>>> fetchInto(Class) is called on a ResultQuery<R>, where R is a generic 
>>>>>> type.
>>>>>> It will be a bit harder to find a solution along the lines of what you're
>>>>>> looking for. Perhaps, we could generate a RecordMapper<TableNameRecord,
>>>>>> TableNamePojo>, which would add some type safety over passing the class
>>>>>> literal (and it could be implemented more optimally). That RecordMapper
>>>>>> could then be made available from TableNameRecord:
>>>>>>
>>>>>> class TableNameRecord extends UpdatableRecordImpl {
>>>>>>     ...
>>>>>>
>>>>>>     public static RecordMapper<TableNameRecord, TableNamePojo>
>>>>>> mapper() { ... }
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> This could then be used as such:
>>>>>>
>>>>>> dsl.select(...).from(...).fetchInto(TableNameRecord.mapper())
>>>>>>
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "jOOQ User Group" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to jooq-user+...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thank you
>>>> Samir Faci
>>>> https://keybase.io/csgeek
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "jOOQ User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jooq-user+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "jOOQ User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jooq-user/7hfDlmEwfQI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jooq-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Luis Artola
[image: Bunt Planet] <http://buntplanet.com/>
Zuatzu Kalea 9. Edificio Europa. Planta 3. 20018 Donostia
T + 34 943 223 031

-- 
You received this message because you are subscribed to the Google Groups "jOOQ 
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jooq-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to