Project

General

Profile

Activity

From 03/06/2020 to 04/04/2020

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

03/06/2020

05:03 AM Feature #4011: database/persistence layer performance improvements
There is this constant:... Ovidiu Maxiniuc
 

Also available in: Atom