Activity
From 04/24/2022 to 05/23/2022
05/23/2022
- 11:44 AM Feature #6348: implement support for MariaDB
- I am interested in taking this as a background task. I worked previously with MySQL so the syntax should be familiar.
05/20/2022
- 02:45 PM Bug #6385: Problem with conversion of REPOSITION TO ROWID with UNKNOWN literal for rowid
- The statement @REPOSITION <query> TO ROWID ? NO-ERROR@ is converted to @silent(() -> <query>.repositionByID(new unkno...
- 02:44 PM Bug #6385 (WIP): Problem with conversion of REPOSITION TO ROWID with UNKNOWN literal for rowid
- 07:47 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- > I don't see this conversion problem for OO in current projects, and if this appears at runtime, then it can be fixe...
- 12:33 AM Feature #6347 (Review): change the name conversion to provide a configurable option to not emit "...
- Implemented in 6129a/13860.
Adds a new, optional @conversion@ attribute to the @schema/namespace@ XML element in @...
05/19/2022
- 10:28 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- Greg Shah wrote:
> It gives type-safety (as much as the 4GL allows) and also would allow overloading.
Yes, this is ... - 09:03 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- It gives type-safety (as much as the 4GL allows) and also would allow overloading.
But it would require a good bit... - 09:02 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- Exactly.
- 08:54 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- Greg Shah wrote:
> > And the conversion will just have field1, field2, instead of 'cost', 'price', etc?
>
> Not i... - 08:52 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- > And the conversion will just have field1, field2, instead of 'cost', 'price', etc?
Not in the business logic. W... - 08:46 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- Greg Shah wrote:
> The idea is that the super-interface would not care about names. It would have a field 1 that is... - 08:43 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- The idea is that the super-interface would not care about names. It would have a field 1 that is the correct type an...
- 08:18 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- Greg Shah wrote:
> My idea was that it would be unpacked as a concreate instance of the right DMO, but internally it... - 08:15 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- > I don't think it helps if we add a generic structural type that matches both DMO types. - if you set this at the pa...
- 03:56 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- Actually, for temp-tables, we emit @TableParameter@ and not the buffer. So this is why it can be handled at runtime....
- 03:50 AM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- Greg Shah wrote:
> The problem here is that our type is too specific. We really need a generic structural type that...
05/18/2022
- 07:00 PM Feature #6379: buffer parameters can work as structural matches (without field name matching)
- Eric wrote some testcases and I extended them and checked them into the old testcases project (see @uast/buffer_param...
- 06:24 PM Feature #6379 (New): buffer parameters can work as structural matches (without field name matching)
- 02:42 PM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- Eric Faulhaber wrote:
> But perhaps that _is_ the way to do it. From what I understand you are saying, the active pr... - 02:22 PM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- Constantin Asofiei wrote:
> Eric, please confirm that your issue is with the 'middle' part, where the schemas/p2os a... - 02:16 PM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- Yes, I think the schema/namespace configuration should only be defined once, in the default profile, and the individu...
- 02:00 PM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- And something else to note: considering that a schema can be part of multiple profiles, I don't think is correct to k...
- 01:48 PM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- The idea with the conversion profiles was that you are splitting the 4GL converted source code in unique sets, with e...
- 01:42 PM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- Eric, please confirm that your issue is with the 'middle' part, where the schemas/p2os are processed.
If yes, we h... - 01:29 PM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- Eric, the default profile is meant to be 'switched' with the file's profile, when TRPL code is ran (see @config.withF...
- 12:55 PM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- Ovidiu, Constantin, with the addition of the profiles feature in @p2j.cfg.xml@, what is the appropriate way now to ch...
05/17/2022
- 10:51 AM Feature #4369: implement stateless FWD server clustering
- Evidently REDIS also has an object synchronization capability. We should evaluate this in addition to the other fram...
- 10:02 AM Feature #6371: implement SAVE CACHE statement
- To be clear: we are not planning to support the idea of saving this cache into a binary file and sharing it across se...
- 09:41 AM Feature #6371: implement SAVE CACHE statement
- The @SAVE CACHE@ language statement allows schema changes to be made to a live database and will read the latest chan...
- 09:29 AM Feature #6371 (Closed): implement SAVE CACHE statement
- 09:58 AM Feature #6372: add a 4GL syntax extension to drop a database table while the database is online/t...
- To delete a table in the OE database, it requires that the application is stopped and no connections are active to th...
- 09:53 AM Feature #6372 (New): add a 4GL syntax extension to drop a database table while the database is on...
05/13/2022
- 11:35 AM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- > I am leaning toward p2j.cfg.xml
Agreed. - 10:59 AM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- I am considering the best place to add this configuration. Currently, we configure persistence name conversion inform...
- 10:45 AM Feature #6347: change the name conversion to provide a configurable option to not emit "snake case"
- The intention is to keep names verbetim except for reserved SQL keywords, hyphens and other invalid SQL name constructs.
05/12/2022
- 08:40 AM Bug #3896: improve performance of the _lock metadata implementation
- Fixed getLockTableUpdater for meta tables.
Committed to 3821c/13875.
05/11/2022
- 02:55 PM Bug #6353: Incompatible data in the _Lock VST
- Comparing the results of the @testcases/locks/locks.p@ I see a number of differences:
# With FWD a see a strange rec... - 02:55 PM Bug #6353 (New): Incompatible data in the _Lock VST
- 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 ...
Also available in: Atom