FWD » Core Development » Database

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). Ovidiu Maxiniuc

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... Igor Skornyakov

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 ... Eric Faulhaber

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... Igor Skornyakov

01:01 PM Bug #3896 (Review): improve performance of the _lock metadata implementation

Eric Faulhaber

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... Igor Skornyakov

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... Eric Faulhaber

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... Igor Skornyakov

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... Eric Faulhaber

04/08/2022

05:04 PM Bug #3896: improve performance of the _lock metadata implementation

Eric Faulhaber wrote:
> Is the latest patch still based on 3821c/13684?
Please find the patch based on 3821c/13... Igor Skornyakov

04:57 PM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> Eric,
> Can you please review this? I cannot commit another changes e.g. for the @Database... Eric Faulhaber

04:17 PM Bug #3896: improve performance of the _lock metadata implementation

Eric,
Can you please review this? I cannot commit another changes e.g. for the @DatabaseManager@ since these changes... Igor Skornyakov

04/06/2022

01:56 PM Bug #6242: PSQLException when creating identity sequence using PostgreSQL dialect

In revision 3821c/13746 I added some code to detect whether the query string returned by p2j dialect when updating th... Ovidiu Maxiniuc

09:48 AM Bug #6242: PSQLException when creating identity sequence using PostgreSQL dialect

When performing database import on a fresh PostgreSQL database using 3821c/13704, we hit:... Eric Faulhaber

09:43 AM Bug #6242 (New): PSQLException when creating identity sequence using PostgreSQL dialect

Eric Faulhaber

03/28/2022

06:53 AM Bug #3896: improve performance of the _lock metadata implementation

Sorry, forgot to add new classes to the .diff file. Igor Skornyakov

06:02 AM Bug #3896: improve performance of the _lock metadata implementation

Finished.
Please review.
Thank you. Igor Skornyakov

03/27/2022

03:21 PM Bug #3896: improve performance of the _lock metadata implementation

Added JMX instrumentation and cleanup logic to @LockTableUpdater@.
However, I have a strange problem with finding pe... Igor Skornyakov

03/25/2022

07:34 AM Bug #3896: improve performance of the _lock metadata implementation

Please note that the @_Lock@ VST cleanup in a separate thread should be a rare event. It will happen only if the lock... Igor Skornyakov

07:11 AM Bug #3896: improve performance of the _lock metadata implementation

Greg Shah wrote:
> I prefer to avoid executors or Java thread pools. It adds hidden logic to manage threads which m... Igor Skornyakov

06:49 AM Bug #3896: improve performance of the _lock metadata implementation

> I'm planning to use a @SingleThreadExecutor@ shared by all instances of the @LockTableUpdater@ for the background @... Greg Shah

05:07 AM Bug #3896: improve performance of the _lock metadata implementation

After fixing an obvious mistake with adding @final@ to the @Empty@ class declaration the smoke test of the large cust... Igor Skornyakov

06:27 AM Feature #6187: eliminate explicit buffer usage in can-find

In my opinion, the converted code will read better with @canFind(...)@ than @new FindQuery(...).hasAny()@. Greg Shah

06:23 AM Feature #6187: eliminate explicit buffer usage in can-find

We really should just implement a set of static @canFind()@ methods which have the @<dmo>.Buf.class@ as a parameter a... Greg Shah

04:30 AM Feature #6187: eliminate explicit buffer usage in can-find

This is still an issue. It can be see with this simple test:... Constantin Asofiei

03/24/2022

03:22 PM Bug #3896: improve performance of the _lock metadata implementation

@LockTableUpdater@ is re-worked in the same way as @UserTableStatUpdater@ was re-worked some time ago. No separated t... Igor Skornyakov

03/18/2022

08:26 AM Feature #6187: eliminate explicit buffer usage in can-find

It seems in 2015, this may already have been resolved (from @record_scoping_prep.rules@):... Greg Shah

03/17/2022

12:38 PM Bug #3896: improve performance of the _lock metadata implementation

Does it make sense to move @LockTableUpdater.UpdateWorker.fileNums@ map to the @MetadataManager@ (as a value of the m... Igor Skornyakov

07:24 AM Feature #6187: eliminate explicit buffer usage in can-find

I don't recall why we require this extra buffer that is not actually a buffer in the 4GL. I do recall how painful th... Greg Shah

07:23 AM Feature #6187 (New): eliminate explicit buffer usage in can-find

Greg Shah