FWD » Core Development » Database

04/07/2020

05:19 PM Feature #4011: database/persistence layer performance improvements

While working with the @hotel_gui@ and in particular with embedded client I feel that FWD is non-deterministically un... Ovidiu Maxiniuc

04:46 PM Feature #3813: misc DB features part deux

The runtime support for the @DEFAULT-STRING@ (modulo the issue with EXTENT fields (see #3813-99) is finished.
Commit... Igor Skornyakov

04:27 PM Feature #3813: misc DB features part deux

Greg Shah wrote:
> Most likely, the initial value for these problem cases should be the unknown value. Please check... Igor Skornyakov

04:24 PM Feature #3813: misc DB features part deux

> I've implemented preventive pre-check in the getDefaultString and do not try to vet the values for the problematic ... Greg Shah

04:01 PM Feature #3813: misc DB features part deux

Greg Shah wrote:
> > Formally this issue is not related to #3813 and does not prevent tesing.
>
> We still should... Igor Skornyakov

03:59 PM Feature #3813: misc DB features part deux

Greg Shah wrote:
> > I've found that current INITIAL attribute support generates exceptions for other data types (su... Igor Skornyakov

03:48 PM Feature #3813: misc DB features part deux

> Formally this issue is not related to #3813 and does not prevent tesing.
We still should probably fix this now. ... Greg Shah

03:37 PM Feature #3813: misc DB features part deux

Greg Shah wrote:
> Igor Skornyakov wrote:
> > On the conversion of the field definition
> > [...]
> > the time pa... Igor Skornyakov

03:31 PM Feature #3813: misc DB features part deux

Another issue:
The converted statement @SessionUtils.setDateFormat(new character("ydm"))@ causes runtime exception:
... Igor Skornyakov

03:30 PM Feature #3813: misc DB features part deux

> I've found that current INITIAL attribute support generates exceptions for other data types (such as raw or even ch... Greg Shah

03:27 PM Feature #3813: misc DB features part deux

Igor Skornyakov wrote:
> On the conversion of the field definition
> [...]
> the time part is lost.
Please show... Greg Shah

03:23 PM Feature #3813: misc DB features part deux

Eric Faulhaber wrote:
> I don't think that was intentional. Please add it if you need it. My advice about @getPrecis... Igor Skornyakov

03:21 PM Feature #3813: misc DB features part deux

In addition to the #3813-95, I've found that current @INITIAL@ attribute support generates exceptions for other data ... Igor Skornyakov

03:09 PM Feature #3813: misc DB features part deux

On the conversion of the field definition... Igor Skornyakov

02:56 PM Feature #3813: misc DB features part deux

Igor Skornyakov wrote:
> Eric Faulhaber wrote:
> > Where @foo@ represents a DMO and @bar@ is a @decimal@ property, ... Eric Faulhaber

01:33 PM Feature #3813: misc DB features part deux

@DEFAULT-STRING@ uses only decimal separator when rendering @DECIMAL@ values. The value of the group separator is not... Igor Skornyakov

11:04 AM Feature #3813: misc DB features part deux

Greg Shah wrote:
> No. A format string is not the same thing as the @DATE-FORMAT@. A format string for @date@ migh... Igor Skornyakov

10:45 AM Feature #3813: misc DB features part deux

> DEFAULT-STRING renders its dates and numeric values in LOCAL format, subject to the DATE-FORMAT and NUMERIC-FORMAT ... Greg Shah

08:23 AM Feature #3813: misc DB features part deux

Greg Shah wrote:
> The @date@, @datetime@, @datetime-tz@, @integer@, @int64@ and @decimal@ classes all are designed ... Igor Skornyakov

08:14 AM Feature #3813: misc DB features part deux

The @date@, @datetime@, @datetime-tz@, @integer@, @int64@ and @decimal@ classes all are designed to format their stat... Greg Shah

07:51 AM Feature #3813: misc DB features part deux

Greg Shah wrote:
> Igor Skornyakov wrote:
> > Do we have methods for rendering date/numeric data using @SESSION:DAT... Igor Skornyakov

07:46 AM Feature #3813: misc DB features part deux

Greg Shah wrote:
> > We need to correctly distinguish between datetime literal and valid expression as NOW. The firs... Igor Skornyakov

07:39 AM Feature #3813: misc DB features part deux

> We need to correctly distinguish between datetime literal and valid expression as NOW. The first question is what c... Greg Shah

07:36 AM Feature #3813: misc DB features part deux

Igor Skornyakov wrote:
> Do we have methods for rendering date/numeric data using @SESSION:DATE-FORMAT@ and @SESSION... Greg Shah

05:45 AM Feature #3813: misc DB features part deux

Do we have methods for rendering date/numeric data using @SESSION:DATE-FORMAT@ and @SESSION:NUMERIC-FORMAT@ attribute... Igor Skornyakov

05:39 AM Feature #3813: misc DB features part deux

Eric Faulhaber wrote:
> Where @foo@ represents a DMO and @bar@ is a @decimal@ property, the following will return th... Igor Skornyakov

04:40 AM Feature #3813: misc DB features part deux

The issue described in the #3813-97 was a result of the following. I've compiled two tests. The TEMP-TABLE @source-da... Igor Skornyakov

03:35 AM Feature #3813: misc DB features part deux

Eric Faulhaber wrote:
> Where @foo@ represents a DMO and @bar@ is a @decimal@ property, the following will return th... Igor Skornyakov

04/06/2020

07:29 PM Feature #3813: misc DB features part deux

Where @foo@ represents a DMO and @bar@ is a @decimal@ property, the following will return the value of DECIMAL from t... Eric Faulhaber

05:43 PM Feature #3813: misc DB features part deux

Igor Skornyakov wrote:
> I cannot find where the value of the DECIMAL option of the field definition is located in t... Igor Skornyakov

05:38 PM Feature #3813: misc DB features part deux

I cannot find where the value of the DECIMAL option of the field definition is located in the conversion artifacts.
... Igor Skornyakov

01:35 PM Feature #3813: misc DB features part deux

Ovidiu Maxiniuc wrote:
> I will schedule working on this issue. 4011a is not yet stable enough, but we'll see whethe... Igor Skornyakov

01:29 PM Feature #3813: misc DB features part deux

> BTW: do I understand correctly that more complicated expressions cannot be used in the @INITIAL@ clause?
TBH, befo... Ovidiu Maxiniuc

12:40 PM Feature #3813: misc DB features part deux

Ovidiu Maxiniuc wrote:
> I am working on 4011a branch, where the field's attributes (including the default value) ar... Igor Skornyakov

12:29 PM Feature #3813: misc DB features part deux

The following field definition... Igor Skornyakov

12:26 PM Feature #3813: misc DB features part deux

I am working on 4011a branch, where the field's attributes (including the default value) are defined as DMO interface... Ovidiu Maxiniuc

11:40 AM Feature #3813: misc DB features part deux

At the moment FWD runtime support if the INITIAL attribute for fields like @FIELD s-datetime AS DATETIME INITIAL NOW@... Igor Skornyakov

09:57 AM Feature #3813: misc DB features part deux

Greg Shah wrote:
> Doesn't the @DEFAULT-VALUE@ of the DMO map more closely to @BUFFER-FIELD:DEFAULT-VALUE@ instead o... Igor Skornyakov

09:50 AM Feature #3813: misc DB features part deux

Doesn't the @DEFAULT-VALUE@ of the DMO map more closely to @BUFFER-FIELD:DEFAULT-VALUE@ instead of using the @DEFAULT... Greg Shah

09:42 AM Feature #3813: misc DB features part deux

We have no support for the BUFFER-FIELD:DEFAULT-VALUE (even conversion is not supported). This can be a little bit tr... Igor Skornyakov

07:34 AM Feature #4011: database/persistence layer performance improvements

Eric Faulhaber wrote:
> Which revision of hotel_gui are you using with 4011a/11404?
I found r202 of hotel_gui is wh... Ovidiu Maxiniuc

04/05/2020

06:08 PM Feature #4011: database/persistence layer performance improvements

Ovidiu Maxiniuc wrote:
> I have committed my latest changes to 4011a as r11404.
> The standalone hotel_gui is start... Eric Faulhaber

07:52 AM Feature #4011: database/persistence layer performance improvements

I have committed my latest changes to 4011a as r11404.
The standalone hotel_gui is starting up and tabs can be navig... Ovidiu Maxiniuc

07:37 AM Feature #4011: database/persistence layer performance improvements

> This is a non-orthodox workaround.
You're being kind. Let us call it what it is: an ugly solution. Unfortunate... Greg Shah

04/04/2020

06:24 PM Feature #4011: database/persistence layer performance improvements

Greg, thanks for suggestion. This is a non-orthodox workaround. Here is what I've done.
I altered @NUM_LITERAL@ in l... Ovidiu Maxiniuc

04/03/2020

06:33 PM Feature #3813: misc DB features part deux

By the end of the weekend, please report the list of open items remaining in this task. We can push the #3813-81 it... Greg Shah

06:31 PM Feature #4011: database/persistence layer performance improvements

Is the column name version of @order@ always "qualified" (e.g. @tt1.order@)? If so, then you can easily differentiat... Greg Shah

05:29 PM Feature #4011: database/persistence layer performance improvements

In fact, @by@ does not suffer from this inconvenient as it is already a Progress reserved keyword and cannot be the n... Ovidiu Maxiniuc

04:59 PM Feature #4011: database/persistence layer performance improvements

I encountered the following issue and I see no easy trick to work around. It is a antlr issue I think. Suppose we hav... Ovidiu Maxiniuc

04/02/2020

08:22 AM Feature #3813: misc DB features part deux

Contrary to what is said in the Progress documentation the @DEFAULT-STRING@ attribute is read-only. This is logical a... Igor Skornyakov

04/01/2020

11:47 AM Feature #4011: database/persistence layer performance improvements

Greg Shah wrote:
> > There is another issue which I have in mind: when creating a savepoint, shouldn't we also sav... Eric Faulhaber

11:36 AM Feature #4011: database/persistence layer performance improvements

Greg Shah wrote:
> What happens if in the meantime between the roll-forward and the original execution of a statem... Eric Faulhaber

07:39 AM Feature #4011: database/persistence layer performance improvements

> maybe, instead of trying to track NO-UNDO DMOs as POJOs, I need to track the SQL statements that were rolled back a... Greg Shah

07:21 AM Feature #4011: database/persistence layer performance improvements

Eric, this FFD replay is the same though I had in mind. I don't think we can keep the database in good condition and ... Ovidiu Maxiniuc

03/31/2020

06:25 PM Feature #4011: database/persistence layer performance improvements

I've been struggling with how to fit a bulk delete (i.e., @delete from <table> [ where <condition> ]@) which operates... Eric Faulhaber

10:14 AM Feature #3813: misc DB features part deux

Working on @BUFFER-FIELD:DEFAULT-STRING@ and @BUFFER-DECIMALS@ attributes support. Igor Skornyakov

03/30/2020

03:51 PM Feature #4011: database/persistence layer performance improvements

Ovidiu Maxiniuc wrote:
> OTOH, in case of the TEMP-TABLEs, there is the case when two independent tables are defin... Eric Faulhaber

11:38 AM Feature #4011: database/persistence layer performance improvements

My concerns on different @extent@ fields were related to @shared@ tables. However, re-reading #2942 notes I see that ... Ovidiu Maxiniuc

09:53 AM Feature #4011: database/persistence layer performance improvements

I really like your proposal as well. It seems "more correct" and it reads better.
In regard to the question "whic... Greg Shah

09:47 AM Feature #4011: database/persistence layer performance improvements

Eric Faulhaber wrote:
> Ovidiu, I like the chaining approach. This is an approach I have adopted with other new APIs... Ovidiu Maxiniuc

09:42 AM Feature #4011: database/persistence layer performance improvements

Constantin Asofiei wrote:
> I think your solution can limit the legacy annotations to only schema-related informatio... Ovidiu Maxiniuc

03/28/2020

04:54 PM Feature #4011: database/persistence layer performance improvements

Ovidiu, I like the chaining approach. This is an approach I have adopted with other new APIs which have lots of possi... Eric Faulhaber

09:57 AM Feature #4011: database/persistence layer performance improvements

Ovidiu, your idea of setting these non-schema settings for a temp-table at the program where it is defined is interes... Constantin Asofiei

03/27/2020

07:44 PM Feature #4011: database/persistence layer performance improvements

We are talking about two different types of 'attributes' of the temp-tables:
* structural (actual data structure, m... Ovidiu Maxiniuc

01:59 PM Feature #4011: database/persistence layer performance improvements

Eric Faulhaber wrote:
> If we were generating different DMO types for differences in certain [temp-]table attributes... Constantin Asofiei

01:34 PM Feature #4011: database/persistence layer performance improvements

I'm pretty sure we were never generating more than one DMO implementation class per DMO interface. These were designe... Eric Faulhaber

01:30 PM Feature #4011: database/persistence layer performance improvements

Ovidiu Maxiniuc wrote:
> Constantin, you are right, one of the @xml-node-name@ s will be lost in this case.
This wa... Constantin Asofiei

01:22 PM Feature #4011: database/persistence layer performance improvements

Constantin, you are right, one of the @xml-node-name@ s will be lost in this case.
However, this is a bug (I can say... Ovidiu Maxiniuc

01:06 PM Feature #4011: database/persistence layer performance improvements

Eric Faulhaber wrote:
> Constantin Asofiei wrote:
> > Eric/Ovidiu: maybe you've already considered, but please keep... Constantin Asofiei

01:01 PM Feature #4011: database/persistence layer performance improvements

Constantin Asofiei wrote:
> Eric/Ovidiu: maybe you've already considered, but please keep in mind also the 'resource... Eric Faulhaber

11:47 AM Feature #4011: database/persistence layer performance improvements

Eric/Ovidiu: maybe you've already considered, but please keep in mind also the 'resource' behavior for temp-tables (w... Constantin Asofiei

11:23 AM Feature #4011: database/persistence layer performance improvements

Less is more. I see no reason a customer would want the same structure duplicated just to get the affect of setting ... Greg Shah

11:20 AM Feature #4011: database/persistence layer performance improvements

Greg Shah wrote:
> > I suppose an alternative is to include NO-UNDO among the criteria which differentiates DMO inte... Eric Faulhaber

11:12 AM Feature #4011: database/persistence layer performance improvements

> I suppose an alternative is to include NO-UNDO among the criteria which differentiates DMO interfaces during conver... Greg Shah

10:55 AM Feature #4011: database/persistence layer performance improvements

So, what I understand from your comment is that the NO-UNDO state is a property of the table the record belongs to (i... Eric Faulhaber

10:40 AM Feature #4011: database/persistence layer performance improvements

How can we test that? The only way is to use @buffer-copy@, but this will copy field by field, not the whole record.
... Ovidiu Maxiniuc

10:30 AM Feature #4011: database/persistence layer performance improvements

I guess the better question is whether it is possible for the same data record to be used by such temp-tables (i.e., ... Eric Faulhaber

09:09 AM Feature #4011: database/persistence layer performance improvements

Eric Faulhaber wrote:
> Ovidiu, if two temp-tables are defined identically, except that one is declared NO-UNDO and ... Ovidiu Maxiniuc

04:28 AM Feature #4011: database/persistence layer performance improvements

Ovidiu, if two temp-tables are defined identically, except that one is declared NO-UNDO and the other is not, do we g... Eric Faulhaber

03/26/2020

05:21 PM Feature #4011: database/persistence layer performance improvements

If the directory has a flag to force everything to be treated as @NO-UNDO@, then I don't see the need for a conversio... Greg Shah

05:04 PM Feature #4011: database/persistence layer performance improvements

Greg Shah wrote:
> > The only value I see is that of pointing out which temp-tables are NOT marked NO-UNDO in the 4G... Eric Faulhaber

04:29 PM Feature #4011: database/persistence layer performance improvements

> The only value I see is that of pointing out which temp-tables are NOT marked NO-UNDO in the 4GL code, which might ... Greg Shah

04:04 PM Feature #4011: database/persistence layer performance improvements

Eric Faulhaber wrote:
> Greg Shah wrote:
>
> > He mentioned that he believes his team never knowingly uses UNDOab... Eric Faulhaber

03:43 PM Feature #4011: database/persistence layer performance improvements

Eric,
IIRC, the @UndoStateProvider@ is used for two reasons:
* to allow the @undo@ property to be lazily set (in s... Ovidiu Maxiniuc

03:10 PM Feature #4011: database/persistence layer performance improvements

Ovidiu, I am implementing the forced NO-UNDO override idea Greg mentioned above, and I have come across @UndoStatePro... Eric Faulhaber

03/23/2020

03:01 PM Feature #4011: database/persistence layer performance improvements

Greg Shah wrote:
> He mentioned that he believes his team never knowingly uses UNDOable temp-tables. In other wor... Eric Faulhaber

02:58 PM Feature #4011: database/persistence layer performance improvements

Greg Shah wrote:
> [...]
> This would mean that the rollback for temp-tables would actually commit when this flag i... Eric Faulhaber

02:25 PM Feature #4011: database/persistence layer performance improvements

I have fixed the issue in entry 157, please disregard it.
The problem was in annotations' path: in the paths were in... Ovidiu Maxiniuc

01:40 PM Feature #4011: database/persistence layer performance improvements

I've was discussing (with a customer) the UNDO/transaction and sub-transaction rework that is happening in this task.... Greg Shah

12:52 PM Feature #4011: database/persistence layer performance improvements

While working on dynamic temp-tables I encountered the following issue: the @AsmClassLoader@ loads the dynamically ge... Ovidiu Maxiniuc

03/19/2020

07:13 PM Feature #4011: database/persistence layer performance improvements

Greg, never mind.
This seems to have something to do with my registration mechanism. It works with other test case... Eric Faulhaber

06:55 PM Feature #4011: database/persistence layer performance improvements

Greg, could you please double-check the @entry@ hook logic for this test case?... Eric Faulhaber

03:51 PM Feature #4011: database/persistence layer performance improvements

Ovidiu Maxiniuc wrote:
> The actual cause of NPW was the fact that the @activeOffset@ was accessed for the @snapshot... Eric Faulhaber

03:26 PM Feature #4011: database/persistence layer performance improvements

The actual cause of NPW was the fact that the @activeOffset@ was accessed for the @snapshot@ of the @dmo@ of the @Rec... Ovidiu Maxiniuc

02:33 PM Feature #4011: database/persistence layer performance improvements

Ovidiu, those places we are seeing the NPE on @BaseRecord.activeBuffer@ seem to be old code where we are calling a se... Eric Faulhaber

03/16/2020

06:33 PM Feature #4011: database/persistence layer performance improvements

In 4011a revision 11402, I have added @Finalizable.entry()@ which is called during @TransactionManager.blockSetup()@ ... Greg Shah

07:11 AM Feature #4011: database/persistence layer performance improvements

Eric Faulhaber wrote:
> Greg, how hard would it be to add a hook for the savepoint processing which is called at the... Greg Shah

04:14 AM Feature #4011: database/persistence layer performance improvements

Greg, how hard would it be to add a hook for the savepoint processing which is called at the same point in the cycle ... Eric Faulhaber

12:17 AM Feature #4011: database/persistence layer performance improvements

Ovidiu, I need a few more days to work through the UNDO code. Some of the features I expected to see (e.g., the track... Eric Faulhaber

01:14 PM Feature #3813: misc DB features part deux

A fixed @CONNECT@ statement rework was committed to the branch 4231b revision 11368. Igor Skornyakov

04:04 AM Feature #3813: misc DB features part deux

Greg Shah wrote:
> If it does not depend on 4335a, you can put it in 4231b. If 4335a is needed first, then wait for... Igor Skornyakov

03/15/2020

06:07 PM Feature #3813: misc DB features part deux

If it does not depend on 4335a, you can put it in 4231b. If 4335a is needed first, then wait for the 4231b rebase fr... Greg Shah

03/14/2020

01:42 PM Feature #3813: misc DB features part deux

I've found the fix for the CONNECT conversion (see #3813-84).
To which branch should I commit it?
Thank you. Igor Skornyakov

06:38 AM Feature #3813: misc DB features part deux

Igor Skornyakov wrote:
> It seems that the CONNECT statement which caused the @gso_241@ fail is incorrect.
> I've ... Igor Skornyakov

03/13/2020

06:57 PM Feature #4011: database/persistence layer performance improvements

Eric Faulhaber wrote:
> Thinking over some of the issues you've been having, I expect the implicit transaction code ... Ovidiu Maxiniuc

06:52 PM Feature #4011: database/persistence layer performance improvements

I am checking out 4011a2 now...
Thinking over some of the issues you've been having, I expect the implicit transac... Eric Faulhaber

06:46 PM Feature #4011: database/persistence layer performance improvements

I have committed my changes to temporary branch 4011a2. Important things:
* @SavepointReversible@ - dead code;
* @C... Ovidiu Maxiniuc

05:54 PM Feature #3813: misc DB features part deux

It seems that the CONNECT statement which caused the @gso_241@ fail is incorrect.
I've added logging and the argume... Igor Skornyakov

03:45 PM Feature #3813: misc DB features part deux

Task branch 4335a was merged to trunk as revision 11345.
The @ConnectionManager@ change was removed before it was ... Greg Shah

03/10/2020

03:31 AM Feature #4011: database/persistence layer performance improvements

Rev 11397 changes the @BaseRecord@ methods @getId()@ and @setId(Long)@ to @primaryKey()@ and @primaryKey(Long)@, resp... Eric Faulhaber