FWD » Core Development » Database

04/13/2020

07:02 PM Bug #3471: incremental conversion is regressed

Greg Shah wrote:
> 5. The design is quite elegant. The fact that the maps and sets in conversion have been replaced... Constantin Asofiei

06:54 PM Bug #3471: incremental conversion is regressed

Code Review Task Branch 3471a Revision 11373
+Part 2+
5. The design is quite elegant. The fact that the maps a... Greg Shah

06:33 PM Bug #3471: incremental conversion is regressed

Greg Shah wrote:
> 1. In the calling locations of @helper.persistCollection()@ it would be better if the types of t... Constantin Asofiei

04:34 PM Bug #3471: incremental conversion is regressed

Code Review Task Branch 3471a Revision 11373
So far, I've very impressed.
+Part 1+
I'm posting the review in... Greg Shah

07:27 AM Bug #3471: incremental conversion is regressed

Greg, 3471a rev 11373 is ready for review Constantin Asofiei

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

Implemented changes suggested by Eric (see #3813-157) and fixed dependency of the DMO instantiation on @SESSION:DATE... Igor Skornyakov

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

Eric Faulhaber wrote:
> No, please don't work on the conversion part. The @LegacyField@ annotation is precisely the ... Igor Skornyakov

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

Igor Skornyakov wrote:
> Greg Shah wrote:
> > Igor: Can you implement the parts of the support except for the looku... Eric Faulhaber

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

Igor, for @LegacyField@ look in @dmo_common.rules@, around line 1780, for code like this:... Constantin Asofiei

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

Greg Shah wrote:
> Igor: Can you implement the parts of the support except for the lookup of the value? Then it can... Igor Skornyakov

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

Greg Shah wrote:
> Eric: I assume you mean that just the backing value is there in the DMO in 4011a. The rest of th... Eric Faulhaber

04/12/2020

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

Eric Faulhaber wrote:
> Igor Skornyakov wrote:
>
> > I'm supposed to work at least on @DECIMALS@ support right no... Greg Shah

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

Eric Faulhaber wrote:
> The other issue is that I had removed the deprecated @BaseRecord.indexOf@ method in my worki... Eric Faulhaber

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

Thanks for fixing up the import.
I had two errors compiling with rev 11406. One was due to a change I have made in... Eric Faulhaber

04/11/2020

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

Eric Faulhaber wrote:
> Sorry, Igor, would not have been giving you implementation advice had I realized Ovidiu alre... Igor Skornyakov

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

Sorry, Igor, would not have been giving you implementation advice had I realized Ovidiu already implemented this feat... Eric Faulhaber

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

Igor Skornyakov wrote:
> I'm supposed to work at least on @DECIMALS@ support right now.
If there is not a criti... Eric Faulhaber

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

Ovidiu Maxiniuc wrote:
> [...]
> Both attributes and can be directly accessed via the new @DmoMetadataManager@ / @D... Eric Faulhaber

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

Ovidiu Maxiniuc wrote:
> Igor, I believe both of the above attributes are members fields in the new @Property@ DMO a... Igor Skornyakov

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

Igor, I believe both of the above attributes are members fields in the new @Property@ DMO annotation of the new persi... Ovidiu Maxiniuc

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

Can anybody help me to understand how the @LegacyField@ annotations are generated? We need at least two fixes for thi... Igor Skornyakov

04/10/2020

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

Eric Faulhaber wrote:
> Igor Skornyakov wrote:
>
> > I need the get the @DECIMALS@ value from the @BufferFieldImp... Igor Skornyakov

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

Igor Skornyakov wrote:
> I need the get the @DECIMALS@ value from the @BufferFieldImpl@ method I do not see how ge... Eric Faulhaber

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

Eric Faulhaber wrote:
> The DMO field will always return a BDT value, never @null@, even if it is unknown value. The... Igor Skornyakov

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

Fixed the issue with @INITIAL@ value parsing for date fields.
Committed with @SessionExport@ support to 4231b revis... Igor Skornyakov

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

I've removed my changes regarding @LogicalTerminal@. Apart from extracting @SessionExports@ operations to a separate ... Igor Skornyakov

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

Greg Shah wrote:
> > I understand that EnvironmentDaemon is not a suitable pattern for the situation with SESSION:DA... Igor Skornyakov

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

> I understand that EnvironmentDaemon is not a suitable pattern for the situation with SESSION:DATE-FORMAT and the ot... Greg Shah

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

I understand that @EnvironmentDaemon@ is not a suitable pattern for the situation with @SESSION:DATE-FORMAT@ and the ... Igor Skornyakov

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

The first revision of import process was committed to 4011a. I have successfully imported the hotel_gui database in b... Ovidiu Maxiniuc

04/09/2020

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

Greg Shah wrote:
> Yes, it will certinly make it better, even if it is not the full solution.
>
> You can patte... Igor Skornyakov

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

Igor Skornyakov wrote:
> BTW: maybe the problem is not with the @SessionUtils@ _per se_, but in the way @SessionExpo... Greg Shah

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

Yes, it will certinly make it better, even if it is not the full solution.
You can pattern it using the @Environ... Greg Shah

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

BTW: maybe the problem is not with the @SessionUtils@ _per se_, but in the way @SessionExports@ is instantiated in th... Igor Skornyakov

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

Greg Shah wrote:
> Yes. This is what I meant by my comment:
>
> > I don't know why we are using SessionUtils on ... Igor Skornyakov

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

Igor Skornyakov wrote:
> A @SESSION:TIMEZONE = 3.@ (@SessionUtils.setTimezone@) causes the same exception as in #381... Greg Shah

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

A @SESSION:TIMEZONE = 3.@ (@SessionUtils.setTimezone@) causes the same exception as in #3813-123 (@No export or no ac... Igor Skornyakov

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