FWD » Core Development » Database

01/20/2015

04:36 PM Bug #2488: replace runtime compilation of dynamic queries

Certainly static expressions will be more efficient to convert, execute, and store at conversion. I'm pretty sure we ... Eric Faulhaber

03:55 PM Bug #2488: replace runtime compilation of dynamic queries

> Don't abandon it just yet...it will not need to do as much as it does now, but this is a good candidate to morph in... Ovidiu Maxiniuc

08:08 PM Bug #2488: replace runtime compilation of dynamic queries

Ovidiu Maxiniuc wrote:
> Attached you can find a first version of 'runtime/interpret_find_query.xml'. It only handle... Eric Faulhaber

01/19/2015

02:36 PM Bug #2488: replace runtime compilation of dynamic queries

Attached you can find a first version of 'runtime/interpret_find_query.xml'. It only handles the simple @find-query@ ... Ovidiu Maxiniuc

08:07 PM Bug #2488: replace runtime compilation of dynamic queries

Ovidiu Maxiniuc wrote:
> If you have the chance to re-run it, please add the string @predicate@ before and, to simpl... Eric Faulhaber

01/17/2015

05:27 PM Bug #2488: replace runtime compilation of dynamic queries

Eric Faulhaber wrote (from Constantin's email):
> The problem here is that at conversion-time the SchemaDictionary (... Eric Faulhaber

01/16/2015

05:46 PM Bug #2488: replace runtime compilation of dynamic queries

BTW, we have implemented a lot of constructor and method matching support already for TRPL itself. Perhaps we can lev... Eric Faulhaber

05:37 PM Bug #2488: replace runtime compilation of dynamic queries

I've taken a look at the code so far and it is a great start! Yes, I agree that the final tree is simpler to deal wit... Eric Faulhaber

03:55 PM Bug #2488: replace runtime compilation of dynamic queries

Eric Faulhaber wrote:
> Sure, I can do that, but are you certain you want to use the current, final version of the J... Ovidiu Maxiniuc

03:41 PM Bug #2488: replace runtime compilation of dynamic queries

Ovidiu Maxiniuc wrote:
> I did some researches on windev01. Progress is not very permissive. The static statements c... Eric Faulhaber

03:30 PM Bug #2488: replace runtime compilation of dynamic queries

Related to the @createAlias@ topic, here's an email exchange I had with Constantin recently:
> Eric,
>
> The prob... Eric Faulhaber

03:28 PM Bug #2488: replace runtime compilation of dynamic queries

> The text of the error message suggests you are passing the same parameter (@dictdb@) for both the @alias@ and @ldbN... Ovidiu Maxiniuc

02:38 PM Bug #2488: replace runtime compilation of dynamic queries

While I am excited that you've begun implementing a solution, I'm curious whether you've found the answers to the que... Eric Faulhaber

02:31 PM Bug #2488: replace runtime compilation of dynamic queries

Ovidiu Maxiniuc wrote:
> I started implementing a small 'interpreting' engine, targeting only the required node/item... Eric Faulhaber

02:25 PM Bug #2488: replace runtime compilation of dynamic queries

I started implementing a small 'interpreting' engine, targeting only the required node/items. In fact at this time, t... Ovidiu Maxiniuc

01/15/2015

03:12 PM Bug #2488: replace runtime compilation of dynamic queries

Ovidiu Maxiniuc wrote:
> Yes, @query-prepare()@ is the big issue. I believe there are no constrains here and any num... Eric Faulhaber

02:58 PM Bug #2488: replace runtime compilation of dynamic queries

Yes, @query-prepare()@ is the big issue. I believe there are no constrains here and any number of buffers can be adde... Ovidiu Maxiniuc

02:53 PM Bug #2488: replace runtime compilation of dynamic queries

OK, so no calls to UDFs, either? That's another way to trigger client-side where clause processing.
If not, it wou... Eric Faulhaber

02:42 PM Bug #2488: replace runtime compilation of dynamic queries

Looking at @find-first()@ method in manual, the predicate expression is very simple, just ... Ovidiu Maxiniuc

02:34 PM Bug #2488: replace runtime compilation of dynamic queries

I think the following would give us a reasonably complex @WhereExpression@:... Eric Faulhaber

01:05 PM Bug #2488: replace runtime compilation of dynamic queries

> I'm not sure how well an interpreted WhereExpression would work. We may still have to fall back to a compiled appro... Ovidiu Maxiniuc

12:47 PM Bug #2488: replace runtime compilation of dynamic queries

Ovidiu Maxiniuc wrote:
> The java/TRLP debate. It's clear that TRPL has the some advantages, but I think that we sho... Eric Faulhaber

12:41 PM Bug #2488: replace runtime compilation of dynamic queries

Ovidiu Maxiniuc wrote:
> The difficulty appears when there are another buffers (and aliases)...
Please explain your... Eric Faulhaber

06:41 AM Bug #2488: replace runtime compilation of dynamic queries

I understand the principle of this approach.
At first sight, it looks rather easy, the where clause and sorting ar... Ovidiu Maxiniuc

02:04 AM Bug #2488: replace runtime compilation of dynamic queries

The basic idea behind this improvement is to continue to use runtime TRPL to convert a query to an in-memory, Java AS... Eric Faulhaber

01/14/2015

01:26 AM Bug #2488: replace runtime compilation of dynamic queries

Dynamically defined queries are parsed and converted at runtime by P2J, then compiled into discrete Java classes usin... Eric Faulhaber

12:48 AM Bug #2488 (Closed): replace runtime compilation of dynamic queries

Eric Faulhaber

01/09/2015

08:02 AM Bug #2482 (WIP): conversion of FIND does not honor NO-LOCK when specified early

Vadim Nebogatov

02:29 AM Bug #2482: conversion of FIND does not honor NO-LOCK when specified early

I found that a FIND statement of the following form is converted without a @LockType.NONE@ lock type:... Eric Faulhaber

02:03 AM Bug #2482 (WIP): conversion of FIND does not honor NO-LOCK when specified early

Eric Faulhaber