Activity
From 04/11/2022 to 05/10/2022
05/11/2022
- 09:53 PM Feature #6348 (WIP): implement support for MariaDB
- 09:36 PM Feature #6347 (WIP): change the name conversion to provide a configurable option to not emit "sna...
- 09:17 PM Feature #6346: coordinate non-converted code JDBC database edits within the 4GL application trans...
- Hand-written Java application code that edits the database needs the ability to include its changes as part of the sa...
- 09:05 PM Feature #6346 (New): coordinate non-converted code JDBC database edits within the 4GL application...
05/10/2022
- 12:28 PM Support #4550: eliminate the need to place the p2jspi.jar in the JVM extension directory
- As part of the shift to Java 11 (#5567), this task should be completed.
05/09/2022
- 06:33 AM Bug #3896: improve performance of the _lock metadata implementation
- Igor Skornyakov wrote:
> Constantin Asofiei wrote:
> > Igor, please test what happens if you try to lock a meta @_u... - 06:10 AM Bug #3896: improve performance of the _lock metadata implementation
- Constantin Asofiei wrote:
> Igor, please test what happens if you try to lock a meta @_user@ record or do an explici... - 05:26 AM Bug #3896: improve performance of the _lock metadata implementation
- Constantin Asofiei wrote:
> What I meant is for @LockTableUpdater.lockChanged@ to do nothing and log a WARNING if th... - 05:22 AM Bug #3896: improve performance of the _lock metadata implementation
- Igor Skornyakov wrote:
> Constantin Asofiei wrote:
> > Igor Skornyakov wrote:
> > > If I understand correctly @Loc... - 04:59 AM Bug #3896: improve performance of the _lock metadata implementation
- Constantin Asofiei wrote:
> Igor Skornyakov wrote:
> > If I understand correctly @LockTableUpdater@ is not created ... - 04:42 AM Bug #3896: improve performance of the _lock metadata implementation
- Igor Skornyakov wrote:
> If I understand correctly @LockTableUpdater@ is not created for the meta database, so I sug... - 04:37 AM Bug #3896: improve performance of the _lock metadata implementation
- Constantin Asofiei wrote:
> Igor Skornyakov wrote:
> > Indeed, the problem is that @meta_user@ is not included neit... - 04:23 AM Bug #3896: improve performance of the _lock metadata implementation
- Igor Skornyakov wrote:
> Indeed, the problem is that @meta_user@ is not included neither to @FILE_NUM@ nor to @FILE_... - 04:16 AM Bug #3896: improve performance of the _lock metadata implementation
- Indeed, the problem is that @meta_user@ is not included neither to @FILE_NUM@ nor to @FILE_NUM_BY_TBL_NAME@ maps in t...
- 03:01 AM Bug #3896: improve performance of the _lock metadata implementation
- Constantin Asofiei wrote:
> In a standalone test use a @create _user.@ and a @find first _user exclusive-lock@.
O... - 02:59 AM Bug #3896: improve performance of the _lock metadata implementation
- In a standalone test use a @create _user.@ and a @find first _user exclusive-lock@.
- 02:41 AM Bug #3896: improve performance of the _lock metadata implementation
- Constantin Asofiei wrote:
> Igor, most likely the abend is from the LockTableUpdater changes - please take a look, t... - 02:29 AM Bug #3896: improve performance of the _lock metadata implementation
- Igor, most likely the abend is from the LockTableUpdater changes - please take a look, this abend is seen in a custom...
- 02:26 AM Bug #3896: improve performance of the _lock metadata implementation
- Constantin Asofiei wrote:
> Igor, please test what happens if you try to lock a meta @_user@ record or do an explici... - 02:12 AM Bug #3896: improve performance of the _lock metadata implementation
- Igor, please test what happens if you try to lock a meta @_user@ record or do an explicit CREATE on the @_user@ table...
05/03/2022
- 09:23 AM Bug #6310: for first "first()", exclusive-lock, raises FWD exception while 4GL raises at the fiel...
- Greg Shah wrote:
> Please create a bug in the Database project for this issue. We will focus on item 1 and then see... - 08:56 AM Bug #6310: for first "first()", exclusive-lock, raises FWD exception while 4GL raises at the fiel...
- Greg Shah wrote:
> In regard to the unrelated issues, make a list and post them here. We will move them to another ... - 08:55 AM Bug #6310 (New): for first "first()", exclusive-lock, raises FWD exception while 4GL raises at th...
05/02/2022
- 09:32 AM Bug #3896 (Closed): improve performance of the _lock metadata implementation
- 08:05 AM Bug #3896: improve performance of the _lock metadata implementation
- Greg Shah wrote:
> Is this complete?
I think so. - 08:04 AM Bug #3896: improve performance of the _lock metadata implementation
- Is this complete?
04/28/2022
- 11:40 AM Feature #1587: implement full support for word indexes
- I encountered in a customer's data dump the following situation:
The @.df@ file looks like this:...
04/27/2022
- 01:29 PM Bug #6301: incorrect initialization of date-related fields with today and now literals
- The issue can be observed at runtime: the "now" moment is not evaluated for each record at the moment the record is c...
- 01:18 PM Bug #6301 (Test): incorrect initialization of date-related fields with today and now literals
- 07:42 AM Bug #3896: improve performance of the _lock metadata implementation
- Eric Faulhaber wrote:
> As noted earlier, I don't want to address this unless we find it's needed. Let's go with the... - 07:34 AM Bug #3896: improve performance of the _lock metadata implementation
- Greg Shah wrote:
> The moment that the @_lock@ table is ever accessed by converted 4GL code, maintenance starts. At... - 07:32 AM Bug #3896: improve performance of the _lock metadata implementation
- Igor Skornyakov wrote:
> Actually, what Eric suggests (the batch VST cleanup) can reduce the duration of the maint... - 07:28 AM Bug #3896: improve performance of the _lock metadata implementation
- The moment that the @_lock@ table is ever accessed by converted 4GL code, maintenance starts. At that point, the @_l...
- 07:22 AM Bug #3896: improve performance of the _lock metadata implementation
- Greg Shah wrote:
> > The actual maintenance starts when the first lock persisted because of the access is released.
... - 07:16 AM Bug #3896: improve performance of the _lock metadata implementation
- > The actual maintenance starts when the first lock persisted because of the access is released.
By "access is rel... - 06:59 AM Bug #3896: improve performance of the _lock metadata implementation
- Greg Shah wrote:
> The moment any access to the @_lock@ table occurs, we start expending CPU cycles maintaining that... - 06:55 AM Bug #3896: improve performance of the _lock metadata implementation
- The moment any access to the @_lock@ table occurs, we start expending CPU cycles maintaining that table. Do I unders...
- 06:47 AM Bug #3896: improve performance of the _lock metadata implementation
- Greg Shah wrote:
> > Moreover, we submit a clean task only if we see that the lock data was persisted.
>
> What d... - 06:39 AM Bug #3896: improve performance of the _lock metadata implementation
- > Moreover, we submit a clean task only if we see that the lock data was persisted.
What do you mean by "persisted... - 06:27 AM Bug #3896: improve performance of the _lock metadata implementation
- Greg Shah wrote:
> > After all, if we expect that user access to the _Lock table will be rare, then the cost of the ... - 06:19 AM Bug #3896: improve performance of the _lock metadata implementation
- > After all, if we expect that user access to the _Lock table will be rare, then the cost of the background maintenan...
- 06:11 AM Bug #3896: improve performance of the _lock metadata implementation
- Greg Shah wrote:
> Eric controls this decision.
>
> I am not suggesting leaving the code as you have written it. ... - 05:54 AM Bug #3896: improve performance of the _lock metadata implementation
- Eric controls this decision.
I am not suggesting leaving the code as you have written it. I am suggesting that th... - 05:47 AM Bug #3896: improve performance of the _lock metadata implementation
- Greg Shah wrote:
> Are we *really, really sure* that this incremental maintenance approach is needed? The @_lock@ d... - 05:36 AM Bug #3896: improve performance of the _lock metadata implementation
- Are we *really, really sure* that this incremental maintenance approach is needed? The @_lock@ data is expected to b...
- 02:27 AM Bug #3896: improve performance of the _lock metadata implementation
- Eric Faulhaber wrote:
> Nevertheless, the above scenario could happen (who knows how developers have instrumented so... - 02:17 AM Bug #3896: improve performance of the _lock metadata implementation
- Eric Faulhaber wrote:
> Well, the block nesting of the test seems a little odd to me, but it should work. You must... - 11:00 PM Bug #3896: improve performance of the _lock metadata implementation
- Igor Skornyakov wrote:
> Eric Faulhaber wrote:
> > Why are we hitting the VST on a state change event? Presumably, ... - 10:20 PM Bug #3896: improve performance of the _lock metadata implementation
- Igor Skornyakov wrote:
> I see some strange results with a simple 4GL test.
> Consider the following program:
> [....
04/26/2022
- 06:24 AM Bug #3896: improve performance of the _lock metadata implementation
- I see some strange results with a simple 4GL test.
Consider the following program:...
04/25/2022
- 04:33 PM Bug #3896: improve performance of the _lock metadata implementation
- Eric Faulhaber wrote:
> Code review @_lock3.diff@ (applied to 3821c/13813):
>
> 1) I didn't notice this when I re... - 03:21 PM Bug #3896: improve performance of the _lock metadata implementation
- Code review @_lock3.diff@ (applied to 3821c/13813):
1) I didn't notice this when I reviewed an earlier version of ...
04/19/2022
- 12:16 PM Bug #6275: SKIP-DELETED-RECORD implementation
- Greg Shah wrote:
> Ovidiu: Please review.
A single question: calls to @stopOnSkippedRecord@ occur on @first@, @ne...
04/13/2022
- 07:06 AM Bug #6275: SKIP-DELETED-RECORD implementation
- Ovidiu: Please review.
- 04:16 AM Bug #6275: SKIP-DELETED-RECORD implementation
- @SKIP-DELETED-RECORD@ was implemented as a part of #5882. In turned out that these changes weren't necessary for fixi...
- 04:02 AM Bug #6275 (Review): SKIP-DELETED-RECORD implementation
- 04:16 AM Bug #3896: improve performance of the _lock metadata implementation
- Reworked based on the code review and tested with a large customer app.
Please review the final version (attached).
04/12/2022
- 06:21 PM Feature #4722 (WIP): data import should be able to run with only the converted application jar fi...
- Partial work in this area was done in recent commits (revisions: 13695, 13746, 13753, 13776 of branch 3821c).
04/11/2022
- 02:08 PM Bug #3896: improve performance of the _lock metadata implementation
- Eric Faulhaber wrote:
> Igor Skornyakov wrote:
>
> > The problem with combining multiple updates into a single tr... - 02:03 PM Bug #3896: improve performance of the _lock metadata implementation
- Igor Skornyakov wrote:
> The problem with combining multiple updates into a single transaction is that we need to ... - 01:51 PM Bug #3896: improve performance of the _lock metadata implementation
- Eric Faulhaber wrote:
> Igor Skornyakov wrote:
>
> > [...]
> > Anyway, I will think how to improve the current l... - 01:01 PM Bug #3896 (Review): improve performance of the _lock metadata implementation
- 12:56 PM Bug #3896: improve performance of the _lock metadata implementation
- Eric Faulhaber wrote:
> Igor Skornyakov wrote:
>
> > [...]
> > Anyway, I will think how to improve the current l... - 12:52 PM Bug #3896: improve performance of the _lock metadata implementation
- Igor Skornyakov wrote:
> [...]
> Anyway, I will think how to improve the current logic.
As I noted, it is ok t... - 12:49 PM Bug #3896: improve performance of the _lock metadata implementation
- Eric Faulhaber wrote:
> @_lock2.diff@ patch code review:
>
> Typo at @FwdJMX@:173: @faild@ -> @failed@.
>
> @L... - 12:19 PM Bug #3896: improve performance of the _lock metadata implementation
- @_lock2.diff@ patch code review:
Typo at @FwdJMX@:173: @faild@ -> @failed@.
@LockTableUpdater@:
Please remov...
Also available in: Atom