FWD » Core Development » Database

05/05/2015

04:17 PM Bug #2570: buffers must be members of the class which defines their tightest scope

There were regressions with naming conflicts. Working on a fix. Eric Faulhaber

12:10 PM Bug #2570: buffers must be members of the class which defines their tightest scope

P2J incorrectly creates all record buffers as instance members of the top level class. Buffers scoped more tightly th... Eric Faulhaber

11:46 AM Bug #2570 (Closed): buffers must be members of the class which defines their tightest scope

Eric Faulhaber

05/02/2015

12:42 AM Bug #2568: Possibly wrong default column label value

P2J returns an empty string if a label or column label is not specified, so it is not clear how distinguish cases whe... Stanislav Lomany

12:36 AM Bug #2568 (New): Possibly wrong default column label value

Stanislav Lomany

04/30/2015

05:21 AM Bug #2562: record updated in a side buffer is not included in query result list

Testcase: ... Stanislav Lomany

05:19 AM Bug #2562 (New): record updated in a side buffer is not included in query result list

Stanislav Lomany

02:26 AM Bug #2561: invalid DEFAULT-BUFFER-HANDLE if a secondary buffer is initialized prior to default bu...

Testcase:... Stanislav Lomany

02:24 AM Bug #2561 (New): invalid DEFAULT-BUFFER-HANDLE if a secondary buffer is initialized prior to defa...

Stanislav Lomany

04/29/2015

11:50 PM Feature #2551 (Closed): replace runtime compilation of DMOs with ASM bytecode implementation

The attached update implements this feature. It passed regression testing and was committed to bzr rev. 10842.
Whe... Eric Faulhaber

04/25/2015

11:38 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

It is difficult to review the 0422a update, because it is built on top of the 0421a update. Since we know we're not k... Eric Faulhaber

04/22/2015

02:23 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

See #1868, note 51 for the primary key search test results with and without the 0421a update. There are 33 new failur... Eric Faulhaber

02:16 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

> Let's not take this on if we don't have to. If your form works and doesn't cause a significant performance penalty,... Ovidiu Maxiniuc

02:13 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Ovidiu Maxiniuc wrote:
> As you can see there is a big failure to properly convert it. An educated guess is that we ... Eric Faulhaber

02:09 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

> Doesn't this simplify to the following?
> @(B != A) or (B is null != A is null)@
>
> Is that valid HQL/SQL? If ... Ovidiu Maxiniuc

01:45 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Ovidiu Maxiniuc wrote:
> I am really sorry I broke your test results. My tests were quite focused on the task, I did... Eric Faulhaber

01:35 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Ovidiu Maxiniuc wrote:
I haven't reviewed the update yet, but to respond to one of your items...
> The most com... Eric Faulhaber

01:23 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

> Yes, I tested this update with the passing and failing tests overnight and it went badly (did not finish, lots of t... Ovidiu Maxiniuc

01:14 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Ovidiu Maxiniuc wrote:
> Eric Faulhaber wrote:
> > Code review 0421a:
> >
> > Looks good, please regression test... Eric Faulhaber

01:04 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Eric Faulhaber wrote:
> Code review 0421a:
>
> Looks good, please regression test. It seems the change to the @Co... Ovidiu Maxiniuc

01:00 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Eric Faulhaber wrote:
> Agreed, we should try this. Hopefully, the @or@ in the where clause does not cause a perform... Ovidiu Maxiniuc

01:44 PM Bug #2554: Temp-tables with different labels / column labels are converted to the same TempRecord...

Conversion bug - two temp-tables with different labels / column labels are converted to the same @TempRecord@ class. ... Stanislav Lomany

01:41 PM Bug #2554 (New): Temp-tables with different labels / column labels are converted to the same Temp...

Stanislav Lomany

04/21/2015

06:59 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Code review 0421a:
Looks good, please regression test. It seems the change to the @CompoundQuery(boolean, boolean)... Eric Faulhaber

04:27 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Agreed, we should try this. Hopefully, the @or@ in the where clause does not cause a performance problem as well.
... Eric Faulhaber

02:12 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Then the only solution is to rewrite the relational operators applied on two fields in the hqls as mentioned in note 15. Ovidiu Maxiniuc

02:09 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Ovidiu Maxiniuc wrote:
> Regarding the remaining bug. Normally a query like @tt2.f1 = tt1.f1@ in SQL will select rec... Eric Faulhaber

02:02 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

The attached update fixes the management of the preprocessed hql. There are some things I am not completely satisfied... Ovidiu Maxiniuc

11:22 AM Bug #2552: bad hql caching prevents queries to position on the correct rows

This seems like a well-reasoned, practical approach. Please post an update for review when you are satisfied with you... Eric Faulhaber

11:07 AM Bug #2552: bad hql caching prevents queries to position on the correct rows

The solution I test at this moment uses a little more memory to save the last configuration of null/unknown values fo... Ovidiu Maxiniuc

04/20/2015

01:41 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Eric Faulhaber wrote:
> Ovidiu Maxiniuc wrote:
> > At this moment I think we should always add components of multip... Ovidiu Maxiniuc

10:23 AM Bug #2552: bad hql caching prevents queries to position on the correct rows

Ovidiu Maxiniuc wrote:
> At this moment I think we should always add components of multiple joined tables with @reso... Eric Faulhaber

08:32 AM Bug #2552: bad hql caching prevents queries to position on the correct rows

I've done some investigations, rewriting the dynamic query from the note 1 as a static iteration and also in a Progre... Ovidiu Maxiniuc

04/17/2015

03:18 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

So, the conversion semantic is being honored correctly, but there is a flaw with our runtime implementation? To help ... Eric Faulhaber

03:10 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

I believe that I found why @resolveOnce = true@.
The converted java code is:... Ovidiu Maxiniuc

02:54 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

@wasInlined()@ seems to work correctly but @resetArgs()@ is not called when it should.
I checked and it is only call... Ovidiu Maxiniuc

02:40 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Ovidiu Maxiniuc wrote:
> The difficulty is identifying when the @HQLPreprocessor@ should be dropped or reset.
The o... Eric Faulhaber

02:21 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Indeed, storing all inlined @HQLPreprocessor@ is not a good idea. Many of them won't ever be reused. The difficulty i... Ovidiu Maxiniuc

02:14 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Ovidiu Maxiniuc wrote:
> Eric,
> In @HQLPreprocessor.get()@ there is a check (line ~454) if the current arguments c... Eric Faulhaber

12:33 PM Bug #2552: bad hql caching prevents queries to position on the correct rows

Eric,
In @HQLPreprocessor.get()@ there is a check (line ~454) if the current arguments contain a null/unknown value.... Ovidiu Maxiniuc

10:49 AM Bug #2552 (WIP): bad hql caching prevents queries to position on the correct rows

When a query iterates over multiple tables joined by a non-mandatory filed, sometimes it will fail to locate the corr... Ovidiu Maxiniuc

10:32 AM Bug #2552 (Closed): bad hql caching prevents queries to position on the correct rows

Ovidiu Maxiniuc

04/16/2015

11:35 AM Feature #2551: replace runtime compilation of DMOs with ASM bytecode implementation

h3. Email discussion w/ Constantin regarding the custom class loader needed for this implementation:
Eric,
Anot... Eric Faulhaber

11:16 AM Feature #2551: replace runtime compilation of DMOs with ASM bytecode implementation

The current implementation of dynamic temp-table support generates a DMO schema AST on the fly and uses TRPL to conve... Eric Faulhaber

11:02 AM Feature #2551 (Closed): replace runtime compilation of DMOs with ASM bytecode implementation

Eric Faulhaber

10:57 AM Bug #2488: replace runtime compilation of dynamic queries

Eric Faulhaber wrote:
> Is there any work left to do on the initial implementation, or any known problems outstandin... Ovidiu Maxiniuc

10:43 AM Bug #2488: replace runtime compilation of dynamic queries

Is there any work left to do on the initial implementation, or any known problems outstanding? If not, I will close t... Eric Faulhaber

09:14 AM Bug #2550 (WIP): update ImportWorker

The @ImportWorker@ contained special handling the now obsolete pwds.txt file. Since we now have a compatible impleme... Ovidiu Maxiniuc

09:07 AM Bug #2550 (Closed): update ImportWorker

Ovidiu Maxiniuc

04/15/2015

02:15 PM Bug #2536: improve dynamic query parser error handling

Code review 0415b:
Looks good, but needs to be merged up to latest version. Assuming you've tested locally, please... Eric Faulhaber

01:22 PM Bug #2536: improve dynamic query parser error handling

The attached update improves message printed on fail to process query string. Depending on the failing token type a d... Ovidiu Maxiniuc

04/10/2015

05:53 AM Bug #2548: buffer/tables names are too aggressively matched in preference to other names

From #1790 note 276 by Constantin Asofiei:
This is a problem with the name resolution: in 4GL, a table can be abbr... Greg Shah

05:52 AM Bug #2548: buffer/tables names are too aggressively matched in preference to other names

As reported in #1790 note 275 by Vadim Gindin:
From time to time I'm facing with the following conversion problem.... Greg Shah

05:52 AM Bug #2548 (New): buffer/tables names are too aggressively matched in preference to other names

Greg Shah