Activity
From 06/23/2020 to 07/22/2020
07/23/2020
- 08:12 PM Feature #4022: upgrade to a newer PostgreSQL release
- > Which version of PostgreSQL are you using?
12.3
> Were you able to leverage the pre-built PL/Java binaries?
I ...
07/22/2020
- 05:20 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> As I think about the addition of the multiplex ID to the L1 key, it occurs to me that we h... - 05:19 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- As I think about the addition of the multiplex ID to the L1 key, it occurs to me that we have a potential memory leak...
- 04:35 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Code review 4011b/11588:
Looks good. The @buffer.isTemporary()@ check can be eliminated in the @FFC.Key@ c'tor, si... - 04:22 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- The new L1 key implemented in r11588. Please update.
- 03:09 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I think it makes sense to encapsulate the several behaviors of the FFC that are required to be different between temp...
- 02:55 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Code review 4011b/11586:
Please see #4796-8, specifically the points about @updateLock@ and about leaking locks. T... - 02:20 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Sorry, you are right. I will prepare a patch for this.
- 02:16 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> Actually no.
> The temp cache for tables-tables are context local. See @FastFindCache.getI... - 02:14 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Actually no.
The cache objects for tables-tables are context local. See @FastFindCache.getInstance(boolean)@. Only t... - 02:03 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu, the fact that you use a @dmoUid@ is not OK for temp-tables. You need to include the multiplex, too.
A @de... - 03:55 PM Feature #4022: upgrade to a newer PostgreSQL release
- Which version of PostgreSQL are you using?
Were you able to leverage the pre-built PL/Java binaries?
Any issues... - 03:40 PM Feature #4022: upgrade to a newer PostgreSQL release
- Import of the customer's data is running.
- 12:48 PM Feature #4022: upgrade to a newer PostgreSQL release
- What is the status with v12.x?
- 03:19 AM Feature #4011: database/persistence layer performance improvements
- Rev 11584 resolves all but the 2f and 3f parts of the test case in #4011-633.
07/21/2020
- 06:46 PM Feature #4022: upgrade to a newer PostgreSQL release
- If 13 is beta, don't use it. Use the latest stable released build.
- 06:24 PM Feature #4022: upgrade to a newer PostgreSQL release
- I'm not able to build the latest pljava 1.5.5 with postgresql 13 beta 2. There're compilation errors caused by incomp...
- 05:55 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- My first instinct was to pull the argument resolution forward from @executeImpl@ to @execute@, but that is a lot of r...
- 03:14 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I found a new issue with FFC.
When we add a new result for the cache, use use the substitution array as part of th... - 02:37 AM Bug #4796: locking regression in RAQ introduced with the FFC
- Eric Faulhaber wrote:
> I had to make one change ...
This was committed as rev 11580. - 02:13 AM Bug #4796: locking regression in RAQ introduced with the FFC
- Code review 4011b/11579:
I had to make one change to get the @RecordLockContext@ directly from @RecordBuffer@, rat...
07/20/2020
- 05:15 PM Bug #4796: locking regression in RAQ introduced with the FFC
- I committed revision 11579. I am unable to test at this moment with customer application.
- 03:13 PM Bug #4796: locking regression in RAQ introduced with the FFC
- It is unfortunate that the @RecordIdentifier@ used in the FF cache and session cache is not the same as can be used f...
- 03:02 PM Bug #4796: locking regression in RAQ introduced with the FFC
- Eric Faulhaber wrote:
> Do you see any holes in this approach?
No. In fact this is even simpler and straightforwa... - 02:50 PM Bug #4796 (WIP): locking regression in RAQ introduced with the FFC
- 02:50 PM Bug #4796: locking regression in RAQ introduced with the FFC
- Eric Faulhaber wrote:
> As I think more about this, we may need to use the cache result only for NO-LOCK requests,... - 02:26 PM Bug #4796: locking regression in RAQ introduced with the FFC
- Ovidiu Maxiniuc wrote:
> I copied the area which handles the locking, but I am trying to avoid code duplication u... - 01:34 PM Bug #4796: locking regression in RAQ introduced with the FFC
- h3. Initial issue:
When we have a FF cache hit, we do not honor the record lock request of the @FIND@. So, a requ... - 01:28 PM Bug #4796 (WIP): locking regression in RAQ introduced with the FFC
- 03:00 PM Bug #4797: review Persistence.load, as called by RAQ.executeImpl
- I think this method is not quite right in 4011b. It will load the record requested and get the lock type, but the @fo...
- 02:57 PM Bug #4797 (New): review Persistence.load, as called by RAQ.executeImpl
07/19/2020
- 07:05 AM Feature #4011: database/persistence layer performance improvements
- I committed rev 11575, which defers storing buffers whose scopes are opened in the @BufferManager.openBuffers@ list, ...
07/17/2020
- 06:37 PM Support #4702: write temp-table performance test cases
- I've added section how to run performance testcases from the new testcases project: https://proj.goldencode.com/proje...
- 10:28 AM Support #4702: write temp-table performance test cases
- The H2 performance testcases have been committed into the new testcases project as rev 668. They have been removed fr...
- 04:42 PM Feature #4022: upgrade to a newer PostgreSQL release
- At this point there is now a PostgreSQL 13.0. I don't think we should waste time on the intermediate versions.
- 04:22 PM Feature #4022: upgrade to a newer PostgreSQL release
- Just a note that the last VM I created used PL/java 1.5.5 and PostgreSQL 10.
- 04:16 PM Feature #4022 (WIP): upgrade to a newer PostgreSQL release
07/16/2020
- 04:23 PM Feature #4011: database/persistence layer performance improvements
- I have committed 4011b/11564, which skips the index lookup in @RAQ.initialize@ if the table being queried has no lega...
- 04:08 PM Feature #4011: database/persistence layer performance improvements
- It seems to be that the message is misleading. If the record fails a unique index validation, that line is in fact un...
- 03:49 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu, based on this comment in @Persister.update@:...
07/15/2020
- 07:49 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Done. Committed as revision 4011b / 11561.
- 07:43 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Looks good. Please merge if you're still there :-)
- 07:30 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> I'm concerned synchronizing on the cache instance might be too coarse for an active system, ... - 06:32 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> Eric,
> I committed r11563. It contains the last two issues: 3-level cache and synchroniza... - 05:26 PM Feature #4033 (WIP): avoid query for FIND unique when the current record in the buffer would matc...
- Eric,
I committed r11563. It contains the last two issues: 3-level cache and synchronization. I must admit I did not... - 04:04 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- It is a bug in @SavepointManager.registerBlockHooks@. We should be differentiating between full and sub-transaction, ...
- 03:55 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> I think if you already have the cache invalidation logic in @SavepointManager@, we should be... - 03:34 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- @SavepointManager@ registers for the same master transaction rollback hook that is leading to this call, so it should...
- 03:21 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> From where is @Session.rollback@ called in this case?... - 03:17 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- From where is @Session.rollback@ called in this case?
- 03:10 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> For the invalidation on UNDO, please see @SavepointManager$Block.rollback(Session)@.
In t... - 10:51 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Greg Shah wrote:
> Now is the time to get this right. The 4GL deals with things at an index level and we should str... - 10:31 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> > * I had a thought or two on dirty database and whether those operation. As long as it do n... - 06:23 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- > I think what we need to do is, just before the loop which rolls back the elements of the @changed@ set, collect the...
- 11:11 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- What is your plan regarding thread safety for the shared form of the cache?
- 11:10 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- For the invalidation on UNDO, please see @SavepointManager$Block.rollback(Session)@.
I think what we need to do is... - 11:02 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> Everything else looks good, though we are still missing synchronization and invalidation o... - 10:49 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Code review 4011c/11561:
In @RAQ.initialize@, it seems we no longer need to make the lookup of the index informati... - 10:16 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> Eric,
>
> I adjusted the code as you suggested. The @findNext@/@findPrevious@ disappeare... - 07:03 PM Feature #3814: more schema metadata
- Greg Shah wrote:
> If it is just for analysis for this task, it is fine. I just want to be clear that we should not... - 06:58 PM Feature #3814: more schema metadata
- If it is just for analysis for this task, it is fine. I just want to be clear that we should not expect to do an imp...
- 06:09 PM Feature #3814: more schema metadata
- Greg,
DMO annotations keeps the properties which are defined in the @.df@ file. They all are already added to the DM... - 05:51 PM Feature #3814: more schema metadata
- We don't want to import this data. Why spend time on this when we want the DMO annotations to hold everything needed...
- 05:32 PM Feature #3814: more schema metadata
- The problems has multiple reasons.
1. The table dump from the Data Administrator skips some fields for the reason I ... - 01:14 PM Feature #4055 (WIP): optimize temp-table output parameter copying
- The changes are in 4011b rev 11559 Please review.
- 06:05 AM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Constantin Asofiei wrote:
> > Eric Faulhaber wrote:
> > > Why not create an array which ma...
07/14/2020
- 07:32 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric,
I adjusted the code as you suggested. The @findNext@/@findPrevious@ disappeared by themselves. By extracting... - 05:47 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> I have just committed r11557 of 4011c.
> Changes:
> * I introduced a numeric identifier f... - 05:39 PM Bug #4760 (WIP): new keywords added in H2 1.4.200
- I've added in 4011b rev 11556 all the keywords not accepted by H2, to @P2JH2Dialect@. NameConverter is not required ...
- 04:30 PM Bug #4760: new keywords added in H2 1.4.200
- Ovidiu Maxiniuc wrote:
> Constantin,
>
> I am not sure, but that these special non-reserved keywords which can be... - 03:49 PM Bug #4760: new keywords added in H2 1.4.200
- Constantin,
I am not sure, but that these special non-reserved keywords which can be used a field/table names migh... - 02:48 PM Bug #4760: new keywords added in H2 1.4.200
- In @org.h2.util.ParserUtil@, there are lots of constants defining various tokens. Not all can be used in a column na...
- 02:42 PM Bug #4760 (Closed): new keywords added in H2 1.4.200
- 05:32 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric Faulhaber wrote:
> > Why not create an array which maps the @PropertyMeta@ objects... - 05:24 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Constantin Asofiei wrote:
> > > Does the destination record need to have a copy of the ... - 04:36 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> > Does the destination record need to have a copy of the source DMO's current meta-state... - 04:35 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Wait, I just looked at this more closely. Is there any functional reason we need to convert ... - 04:33 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> A question which remains in my mind w.r.t. the copy operations is about LOBs. Will this work... - 03:49 PM Feature #4011: database/persistence layer performance improvements
- A question which remains in my mind w.r.t. the copy operations is about LOBs. Will this work for LOBs in their curren...
- 03:36 PM Feature #4011: database/persistence layer performance improvements
- Wait, I just looked at this more closely. Is there any functional reason we need to convert to/from BDT instances? If...
- 03:22 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> As I mentioned above, I had to change @Record.getData()@ to expose the @data[]@ array ... - 03:19 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Constantin Asofiei wrote:
>
> > For copying the after-table record to before-table, I can... - 03:01 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> For copying the after-table record to before-table, I can use something like this, as ... - 02:38 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric Faulhaber wrote:
> > Since this temp-table copy is a common operation, I would l... - 12:45 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> So, @copyDMO@ needs review anyway, as it may be broken, but that is outside the scope of you... - 02:23 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> At this point, what is left is:
> # improve @RecordBuffer.copyDMO@ (see #4011-773)
I n... - 12:47 PM Feature #4055: optimize temp-table output parameter copying
- At this point, what is left is:
# improve @RecordBuffer.copyDMO@ (see #4011-773)
# refactor @TemporaryBuffer.copyAl... - 01:45 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, have you found any other potential areas of improvement in H2, based on any of the testing/profiling you have...
- 01:43 PM Support #4701: try to improve H2 transaction commit performance
- Constantin Asofiei wrote:
> Is there a place in the H2 source-code where all keywords are defined?
I am not fa... - 09:42 AM Support #4701: try to improve H2 transaction commit performance
- Eric/Adrian/Stanislav: H2 v 1.4.200 introduced new keywords, for example @array@. This statement works with 1.4.197 ...
- 08:01 AM Support #4701: try to improve H2 transaction commit performance
- After Java profiling the #4701-17 testcase, I got the following results for 1.4.200 patched:
!profiling_mv_vs_page... - 06:50 AM Support #4701: try to improve H2 transaction commit performance
- Below there is a comparison between 1.4.197 patched using PageStore, 1.4.200 patched using PageStore and 1.4.200 usin...
07/13/2020
- 06:40 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I have just committed r11557 of 4011c.
Changes:
* I introduced a numeric identifier for indexes. In fact, the were ... - 04:46 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- OK, let's use @RecordIdentifier@. We may need to intern the strings, but this has a performance cost of its own. In t...
- 04:24 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> Why is the @FastFindCache$Result@ class necessary? I am not sure what the @L1Key@ and @L2Key... - 03:27 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I reviewed the implementation as of 4011c/11555. In addition to my previous answers in #4033-31, which among other th...
- 05:55 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> Since we currently use an internal counter to assign the next primary key for temp-tables (o... - 05:53 PM Feature #4055: optimize temp-table output parameter copying
- Since we currently use an internal counter to assign the next primary key for temp-tables (or the reclaimed keys), ho...
- 05:49 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> The INSERT INTO ... SELECT FROM ... syntax documented for H2 suggests that the SELECT portio... - 05:43 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> I need them to be incremental so I can make some assumptions;...
OK, that's what I wa... - 05:26 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> I don't know of a way to force the SELECT to use a particular index with H2. That is up to t... - 05:11 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> Eric Faulhaber wrote:
> > I don't follow. Isn't this what we want? Each @_multiplex@ va... - 05:03 PM Feature #4055: optimize temp-table output parameter copying
- Given an sql index name, how can I get its component fields, using the new RecordMeta/DmoMeta/etc support?
Or bett... - 04:29 PM Feature #4055: optimize temp-table output parameter copying
- Well, I remember now. I had the same epiphany when I implemented @write-xml@ and compare the xml output with informat...
- 04:22 PM Feature #4055: optimize temp-table output parameter copying
- Ovidiu Maxiniuc wrote:
> Constantin Asofiei wrote:
> > Ovidiu, please remind me - what's the default index for the ... - 03:28 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> I don't follow. Isn't this what we want? Each @_multiplex@ value represents a distinct temp-... - 03:24 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> H2 will use the @_multiplex@ index and after that sort the records by @recid@.
>
> ... - 03:16 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> Ovidiu, please remind me - what's the default index for the before-table? I recall somet... - 02:59 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> Constantin Asofiei wrote:
> > New question: why don't we have a @multiplex, recid@ default ... - 02:41 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> New question: why don't we have a @multiplex, recid@ default index for temp-tables?
W... - 02:31 PM Feature #4055: optimize temp-table output parameter copying
- New question: why don't we have a @multiplex, recid@ default index for temp-tables?
- 02:25 PM Feature #4055: optimize temp-table output parameter copying
- There's an issue with using @nextVal@ in a SELECT. Looks like the sequence values are retrieved FIRST (I don't know ...
- 01:34 PM Feature #4055: optimize temp-table output parameter copying
- Ovidiu, please remind me - what's the default index for the before-table? I recall something like @row-state@ being p...
- 11:07 AM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> Argh, I haven't realized before that the sequences are global - and if we define it as @... - 10:14 AM Feature #4055: optimize temp-table output parameter copying
- Argh, I haven't realized before that the sequences are global - and if we define it as @seq_tt1@, any user working on...
- 04:24 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Unfortunately, we cannot use @dst.copy(src)@ as the order of fields is not the same, even i... - 04:22 PM Feature #4011: database/persistence layer performance improvements
- Unfortunately, we cannot use @dst.copy(src)@ as the order of fields is not the same, even if the set of the fields ar...
- 04:17 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Constantin,
>
> Please verify whether
> [...]
> and
> [...]
>
> are compatible in... - 02:17 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> I wonder if we are missing out on an opportunity caused by the 4GL behavior here. It is my under... - 02:01 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric, I've fixed @RecordBuffer.copyDMO@ (including extent fields), but I need some input... - 01:41 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Eugenie Lyzenko wrote:
> > The @4011b@ rev @11555@ runtime does not with previously convert... - 01:16 PM Feature #4011: database/persistence layer performance improvements
- Eugenie Lyzenko wrote:
> The @4011b@ rev @11555@ runtime does not with previously converted application/DB.
>
> D... - 12:36 PM Feature #4011: database/persistence layer performance improvements
- The @4011b@ rev @11555@ runtime does not with previously converted application/DB.
Do I have to reconvert/re-impor... - 11:50 AM Feature #4011: database/persistence layer performance improvements
- Constantin,
Please verify whether... - 11:43 AM Feature #4011: database/persistence layer performance improvements
- I wonder if we are missing out on an opportunity caused by the 4GL behavior here. It is my understanding that the co...
- 11:07 AM Feature #4011: database/persistence layer performance improvements
- Eric, I've fixed @RecordBuffer.copyDMO@ (including extent fields), but I need some input with how you would like thin...
- 09:14 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Actually, no.
> IIRC, that method will work with different DMO definitions: the method wor... - 08:26 AM Feature #4011: database/persistence layer performance improvements
- Actually, no.
IIRC, that method will work with different DMO definitions: the method worked passing two temp-tables ... - 07:39 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu, one more thing please: @TemporaryBuffer.copyDMO@ no longer works in 4011b, as there are no declared fields in...
- 07:32 AM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Ovidiu, a call like @ScrollableResults.get(0, TempRecord.class)@ is not valid in FWD, ri... - 07:22 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu, a call like @ScrollableResults.get(0, TempRecord.class)@ is not valid in FWD, right? We should use @Scrollabl...
- 02:29 PM Feature #3814: more schema metadata
- Igor Skornyakov wrote:
> I'm trying to create an H2 database containing all metatables from a large customer databas... - 02:02 PM Support #4702: write temp-table performance test cases
- In the chart it should be "197", not "192".
- 02:00 PM Support #4702: write temp-table performance test cases
- According to test results, MVStore (mv_store=true) is significantly slower than PageStore (mv_store=false). The red s...
- 04:08 AM Support #4702: write temp-table performance test cases
- Yes, I'd like to see a comparison of your tests with:
* 1.4.197 (patched) PageStore
* 1.4.200 (patched) PageStore... - 03:58 AM Support #4702: write temp-table performance test cases
- > BTW, did you do any testing with the MVStore engine? In my previous experience, FWD was slower with MVStore, but I ...
- 03:49 AM Support #4702: write temp-table performance test cases
- > Do they claim this?
They do: https://webcache.googleusercontent.com/search?q=cache:OZQ8T12NI00J:https://github.c... - 03:44 AM Support #4702: write temp-table performance test cases
- Stanislav Lomany wrote:
> PageStore engine is always single-threaded
Do they claim this? That doesn't seem righ... - 03:38 AM Support #4702: write temp-table performance test cases
- > The removal of @MULTI_THREADED@ (from H2, not 4011b) is a little concerning. Do you have any more information on wh...
- 02:24 AM Support #4702: write temp-table performance test cases
- Eric Faulhaber wrote:
> Please go ahead and commit these changes to 4011b, since we are moving to v1.4.200 now for... - 11:21 AM Support #4701: try to improve H2 transaction commit performance
- > Adrian, I should have confirmed this at the beginning, but was your performance comparison work done with the MVSto...
- 04:32 AM Support #4701: try to improve H2 transaction commit performance
- Constantin Asofiei wrote:
> Adrian Lungu wrote:
> > By this, I mean that the synchronization in @Session.cleanTempT... - 03:45 AM Support #4701: try to improve H2 transaction commit performance
- Adrian, I should have confirmed this at the beginning, but was your performance comparison work done with the MVStore...
- 03:20 AM Support #4701: try to improve H2 transaction commit performance
- Adrian Lungu wrote:
> By this, I mean that the synchronization in @Session.cleanTempTables@ is done way more rare (t... - 02:28 AM Support #4701: try to improve H2 transaction commit performance
- Eric Faulhaber wrote:
> Adrian, we will start using this version of H2 (i.e., 1.4.200, patched) as the default with ... - 02:26 AM Support #4701: try to improve H2 transaction commit performance
- We have upgraded to H2 v1.4.200 (patched), starting with 4011b/11555.
07/11/2020
- 09:09 AM Support #4701: try to improve H2 transaction commit performance
- I attached the @src/main/org/h2/engine/Session.java@ file.
> # A lot of users are accessing the database. @org.h2... - 09:51 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> The @Session@ works with its 'proprietary' @CacheKey@ key. I switched to it (making it pu... - 08:48 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> Is there a practical problem caused by the temp-table IDs not being re-usable, or is the pro...
07/10/2020
- 06:15 PM Support #4702: write temp-table performance test cases
- Stanislav Lomany wrote:
> For the case I'm attaching changes I made to 4011b in order to run H2 200 which are:
>
... - 05:18 PM Support #4702: write temp-table performance test cases
- For the case I'm attaching changes I made to 4011b in order to run H2 200 which are:
# @Constants.getFullVersion()@ ... - 05:13 PM Bug #4752: Possible broken sort clause with word indexes
- While working on other issues related to WORD indexes I realized something that seems like needing further investigat...
- 05:05 PM Bug #4752 (New): Possible broken sort clause with word indexes
- 03:55 PM Feature #3814: more schema metadata
- I'm trying to create an H2 database containing all metatables from a large customer database for a detailed analysis....
- 03:03 PM Support #4701: try to improve H2 transaction commit performance
- Adrian Lungu wrote:
> # A lot of local temp-tables are used concurrently.
This is something in use by customer appl... - 12:49 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, we will start using this version of H2 (i.e., 1.4.200, patched) as the default with 4011b. Please update the ...
- 09:49 AM Support #4701: try to improve H2 transaction commit performance
- The @org.h2.Session.cleanTempTables@ direction was a good starting point. H2 was sequentially checking all local temp...
- 02:56 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Are there really no other cases where the buffer scope can be smaller than the external proc... - 02:16 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Here I considered that @activeScopeDepth@ is the scope depth where the buffer was open... - 01:38 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I left the topic of synchronization pretty open. Could you please tell me what your thoughts are there? Of course, th...
- 12:43 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu Maxiniuc wrote:
> More details from 4011c/11554:
> * I added a table/DMO unique ID. This (the Level1key) is ...
07/09/2020
- 06:45 PM Support #4702: write temp-table performance test cases
- Testing results: each test is faster on H2 200 (fwd-h2-1.4.200-20200709) than on H2 197, in average 13% faster.
Test... - 04:44 PM Support #4702: write temp-table performance test cases
- I made some changes to FWD to make H2 200 run. Starting testing.
- 02:03 PM Support #4702: write temp-table performance test cases
- Stanislav, I will try to reproduce the exception and see if it related to @fwd-h2-1.4.200-20200709.jar@.
I remember... - 01:08 PM Support #4702: write temp-table performance test cases
- Results so far:
# Looks like "UPDATE using a query" test goes to infinite cycle in 4011b (H2 197) if the number of r... - 05:16 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> Constantin: I have the following questions about @RecordBuffer.worldScope@.
>
> * Is the idea ... - 02:16 PM Feature #4011: database/persistence layer performance improvements
- Eric, something else to consider. In @Persister.insert@, we use @1 + sum(distinct field's extent)@ INSERT statements...
- 09:52 AM Feature #4011: database/persistence layer performance improvements
- I've generated several reports and exports at the @Guests@ tab. The only meaningful hotspot is:...
- 09:15 AM Feature #4011: database/persistence layer performance improvements
- The profiling of the Hotel GUI app (switching tabs) did not reveal any hot spots. The only thing which is worth to me...
- 01:46 AM Feature #4011: database/persistence layer performance improvements
- After patching directory.xml what I have for freshly imported DB and server start up:...
- 09:26 PM Feature #4011: database/persistence layer performance improvements
- Constantin: I have the following questions about @RecordBuffer.worldScope@.
* Is the idea that @worldScope == true... - 03:16 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> A small note about the reclaimed keys - for the @INSERT INTO SELECT FROM@ approach to wo... - 03:00 PM Feature #4055: optimize temp-table output parameter copying
- A small note about the reclaimed keys - for the @INSERT INTO SELECT FROM@ approach to work, I need consecutive, incre...
- 01:12 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> What is the exact problem in the @INSERT INTO ... SELECT FROM@ case? Maybe we can disable re... - 12:36 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> Eric, a problem @INSERT INTO ... SELECT FROM@ is the primary key. How important is to u... - 12:20 PM Feature #4055: optimize temp-table output parameter copying
- For the PK generation, I'm using sequences (one per each temp-table) like this:
# before the @INSERT INTO ... SELECT... - 03:06 AM Feature #4055: optimize temp-table output parameter copying
- Eric, a problem @INSERT INTO ... SELECT FROM@ is the primary key. How important is to use the 'reclaimed keys' featu...
- 02:44 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- More details from 4011c/11554:
* I added a table/DMO unique ID. This (the Level1key) is the only place used, yet. Th...
07/08/2020
- 04:29 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Please note I have made some updates to #4033-22 to clarify handling of the "no record found" case.
- 04:05 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu wrote (in email):
> I have created the general stubbing for the advanced cache but for the moment I do not ... - 04:00 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- FOR FIRST/LAST already is implemented by @RandomAccessQuery@, so we should get that for free.
FIND CURRENT should ... - 08:07 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Can we expand this usage beyond @FIND@?
It seems to me that the 4GL uses the same index-based technique for these ... - 07:28 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I've tested this and modified your test case somewhat to stress the caching in different ways, and this definitely se...
- 03:20 PM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> Constantin, I linked this with issue #3958 because it seems we should apply some of the same... - 02:28 PM Feature #4055: optimize temp-table output parameter copying
- Constantin, I linked this with issue #3958 because it seems we should apply some of the same ideas to both problems, ...
- 03:09 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Agreed. Are you working on this, or do you want someone else to pick it up?
The fix was sim... - 02:52 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric Faulhaber wrote:
> > Does this patch work?
> >
> > [...]
> Well, my patch just... - 12:01 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Does this patch work?
>
> [...]
Well, my patch just returned the correct 'nextStart' by ... - 08:26 AM Feature #4011: database/persistence layer performance improvements
- There is a bug related to validation/flushing. I have a record like this:...
- 02:39 PM Bug #4057: h2 performance degradation
- Stas, when do you think you will have findings, based on the #4702 test cases? Based on the comparison of versions in...
- 08:57 AM Feature #3814: more schema metadata
- Can we ask our customers (or at least some of them) to provide an export (.d files) of the meta-tables from their 4GL...
07/07/2020
- 07:34 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Eric Faulhaber wrote:
> Ovidiu, please prototype a basic query results cache for use with FIND {FIRST|LAST|unique} q... - 06:07 PM Feature #4011: database/persistence layer performance improvements
- Does this patch work?...
- 05:49 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> What is the layout of the result set you are working with?
There are 3 SELECT being execute... - 05:43 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric, my problem is that @props@ for the @MetaField@ DMO has its structure like this:
>... - 05:35 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> A side note: for a @FindQuery.canFindImpl@ call, do we really need to load the full reco... - 05:32 PM Feature #4011: database/persistence layer performance improvements
- A side note: for a @FindQuery.canFindImpl@ call, do we really need to load the full record in the database? Because t...
- 05:25 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> And if I switch it to @i = i + seriesSize@, then the @i@ will be wrong, but the return v... - 05:21 PM Feature #4011: database/persistence layer performance improvements
- Eric, my problem is that @props@ for the @MetaField@ DMO has its structure like this:
# 52 scalar props
# 48 entrie... - 05:14 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Generally speaking, the data should always be laid out as described in the @Loader@ class ... - 05:11 PM Feature #4011: database/persistence layer performance improvements
- Before you make any changes at this low level, please explain the error you are seeing, which you are trying to solve.
- 05:09 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric/Ovidiu, someone please document and explain how @Loader.readExtentData@ should work... - 05:03 PM Feature #4011: database/persistence layer performance improvements
- Looking at the code, the protection against 'bad data' is not OK. The code should attempt to read exactly 'extent' r...
- 04:02 PM Feature #4011: database/persistence layer performance improvements
- Eric/Ovidiu, someone please document and explain how @Loader.readExtentData@ should work. My change which increments...
- 03:37 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> 4011b contains the fix for #4011-730 and other misc - please review.
The changes seem... - 02:56 PM Feature #4011: database/persistence layer performance improvements
- 4011b contains the fix for #4011-730 and other misc - please review.
- 10:44 AM Feature #4011: database/persistence layer performance improvements
- There is an issue with the @ProxyAssembler.assembleClass@ code. Here, we want to override all passed methods, and als...
- 03:31 PM Bug #4703 (Hold): investigate whether performance of TempTableDataSourceProvider can be improved
- 11:19 AM Support #4701: try to improve H2 transaction commit performance
- I created a test with 1000 temp-tables and the suggested loop. The transaction is in fact committed after each iterat...
- 03:26 AM Feature #3814: more schema metadata
- Igor Skornyakov wrote:
> Fixed the issue with the @null@ @ConnectionListener@ found in automated regression testing ...
07/06/2020
- 05:17 PM Feature #3814: more schema metadata
- Fixed the issue with the @null@ @ConnectionListener@ found in automated regression testing by Roger
Committed to 382... - 02:42 PM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I want to finish the refactoring of the index support from strings to bit sets before we invest time in any conversio...
- 07:12 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- I understand. I just want us to keep in mind that it is easily possible to add a parameter to the query init that is...
- 06:20 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Greg Shah wrote:
> > Storing the index will require we look up the index for all such queries in RAQ.initialize, not... - 06:06 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- > Storing the index will require we look up the index for all such queries in RAQ.initialize, not just when we have a...
- 05:16 AM Feature #4033: avoid query for FIND unique when the current record in the buffer would match the ...
- Ovidiu, please prototype a basic query results cache for use with FIND {FIRST|LAST|unique} queries. The keys are a un...
- 02:11 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> As part of this work, I've written changes to @ScopedDictionary@ to eliminate the use of the @Lis... - 12:55 PM Feature #4011: database/persistence layer performance improvements
- I'm still analyzing the @RecordBuffer.pinnedLockTypes@ usage.
As part of this work, I've written changes to @Scope... - 04:32 AM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> *2.* Make @undone@ an instance member of @RecordBuffer@ instead of using the @extra@ object of ... - 12:43 PM Support #4701: try to improve H2 transaction commit performance
- Constantin Asofiei wrote:
> Adrian, in my profiling, I saw a significant time being spent in @orh.h2.Session.cleanTe... - 12:03 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, in my profiling, I saw a significant time being spent in @orh.h2.Session.cleanTempTables@. Please create a t...
- 11:49 AM Support #4701: try to improve H2 transaction commit performance
- I investigated the H2 sources and eventually tried out some optimizations, but without any considerable performance b...
- 12:27 PM Bug #4742: heap usage increase on server startup
- 3821c rev 11387 contains the changes for this. @hbm_dmo_index.xml@ no longer exists in 4011b, and I'll postpone the ...
- 06:44 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- Eric Faulhaber wrote:
> I don't think it is really worth it to contrive something in hand-written Java to recreate a... - 06:16 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- I don't think it is really worth it to contrive something in hand-written Java to recreate a problem that we haven't ...
- 06:03 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- Eric Faulhaber wrote:
> This is good news, but it suggests that the test did not recreate the condition I thought it... - 05:51 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- This is good news, but it suggests that the test did not recreate the condition I thought it would, either because I ...
07/05/2020
- 07:34 PM Bug #4742: heap usage increase on server startup
- Eric, after clearing the H2 meta from the heap, a real leak appeared, related to my TRPL changes for incremental conv...
- 06:04 PM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> Eric, what's the proper way to ensure the Hibernate session is really flushed of cache... - 05:58 PM Bug #4742: heap usage increase on server startup
- Igor Skornyakov wrote:
> The issue described at #4742-12 is a result of the fact that the login/password for the met... - 03:52 PM Bug #4742: heap usage increase on server startup
- Igor, thanks for the help. The server heap was reduced with ~300MB, which is the size of the _meta database on disk,...
- 02:03 PM Bug #4742: heap usage increase on server startup
- The issue described at #4742-12 is a result of the fact that the login/password for the metadatabase is generated at ...
- 07:18 AM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> Igor, what URL needs to change so that the H2 meta database is on disk, instead of memor... - 06:03 AM Bug #4742: heap usage increase on server startup
- Igor, what URL needs to change so that the H2 meta database is on disk, instead of memory?
Please create a patch f... - 06:02 AM Bug #4742: heap usage increase on server startup
- From Eric:
> If all this data is correct and needed (i.e., there is not a bug/leak), we should take the metadata dat... - 05:46 AM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> Constantin Asofiei wrote:
> > ... and post here a list of all new fields added plus the... - 04:59 AM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> ... and post here a list of all new fields added plus their extent, in each table.
Look... - 04:55 AM Bug #4742: heap usage increase on server startup
- Igor, please do this: compare the standard.df we switched to in #3814 with the attached one (which is an old version,...
- 04:42 AM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> Igor, I have these stats:
> [...]
>
> Do you know if before you made your changes, t... - 04:30 AM Bug #4742: heap usage increase on server startup
- Igor, I have these stats:...
- 03:48 AM Bug #4742: heap usage increase on server startup
- In fact, albeit meta.xml is still parsed on startup, very few records are actually created from it (see the log). It ...
- 07:29 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> *1.* Eliminate the call to @TriggerTracker.resetState()@ from @RecordBuffer.enterBlock()@.
> [... - 04:59 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Greg Shah wrote:
> > Is the primary problem this loop in @beginTx()@ and similar in @en...
07/04/2020
- 06:58 PM Bug #4742: heap usage increase on server startup
- Constantin Asofiei wrote:
> So this allows multiple records for the same file (and if my interpretation of the code ... - 06:28 PM Bug #4742: heap usage increase on server startup
- In a large customer application, it was noticed a heap usage increase on a freshly started FWD server. The assumptio...
- 06:07 PM Bug #4742 (New): heap usage increase on server startup
- 05:59 PM Support #4702: write temp-table performance test cases
- There is an issue running the update tests with 4011b/11544. Looks like we are getting into an infinite loop based on...
07/03/2020
- 06:36 PM Feature #4011: database/persistence layer performance improvements
- I don't understand how @Loader.readExtentData@ worked before. Shouldn't it increase the @i@ var by the @seriesSize@...
- 02:49 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> Is the primary problem this loop in @beginTx()@ and similar in @endTx()@:
Exactly. The global sc... - 02:47 PM Feature #4011: database/persistence layer performance improvements
- Is the primary problem this loop in @beginTx()@ and similar in @endTx()@:...
- 01:26 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> In email, Constantin wrote:
>
> > @BufferManager.beginTx@ and @endTx@ both stand out in t... - 01:05 PM Feature #4011: database/persistence layer performance improvements
- In email, Constantin wrote:
> @BufferManager.beginTx@ and @endTx@ both stand out in the visualvm sampler. This is... - 04:34 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> I see, then we have a problem. The same API is used for INSERT/UPDATE statements. When a DT... - 04:34 PM Support #4701: try to improve H2 transaction commit performance
- I attached the patch based on @h2_synchronization_transactional_fix_20200703a.patch@, but compatible with the 1.4.200...
- 02:56 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, please post the clean patches for the 1.4.200 source code base. Unless Stanislav's findings are vastly differ...
- 02:44 PM Support #4701: try to improve H2 transaction commit performance
- Stanislav,
I attached the h2 versions I used in testing. I can't attach the already built ones as they are too bi... - 09:34 AM Support #4701: try to improve H2 transaction commit performance
- Adrian, could you share 197 patched and 200 patched?
- 07:33 AM Support #4701 (WIP): try to improve H2 transaction commit performance
- 07:33 AM Support #4701: try to improve H2 transaction commit performance
- I have computed the testing results for 1.4.200 and 1.4.200 patched. The spreadsheet is attached and a representative...
- 04:16 PM Support #4702: write temp-table performance test cases
- FYI, I added some missing EOL markers to @perf-run-all-silent.p@ and committed the fix.
- 02:00 PM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- I've tested calling one of Stanislav's tests (with minor changes to suppress output) as an external program in loop:
...
07/02/2020
- 07:36 PM Support #4702 (Review): write temp-table performance test cases
- I've committed all of the tests, including FOR EACH, FIND and BUFFER-COPY tests.
- 05:59 PM Support #4702: write temp-table performance test cases
- Eric Faulhaber wrote:
> Eric Faulhaber wrote:
>
> > I would like at least one test which "thrashes" JDBC connecti... - 06:28 AM Support #4702: write temp-table performance test cases
- Eric Faulhaber wrote:
> I would like at least one test which "thrashes" JDBC connections. That is, the test should... - 06:12 AM Support #4702: write temp-table performance test cases
- Stanislav Lomany wrote:
> Igor, I'm not managing connection. I suppose that is a part of your task.
> BTW, I just c... - 05:53 AM Support #4702: write temp-table performance test cases
- > Which of your tests is supposed to open/close multiple JDBC Connections?
Igor, I'm not managing connection. I su... - 04:21 AM Support #4702: write temp-table performance test cases
- Stanislav.
Which of your tests is supposed to open/close multiple JDBC Connections?
Thank you. - 04:58 PM Support #4701: try to improve H2 transaction commit performance
- Just found this in the H2 v1.4.200 change log, as something that was fixed:
* Issue # 1820: Performance problem on... - 04:05 PM Support #4701: try to improve H2 transaction commit performance
- I shared the findings in #4057. I will go ahead with testing the 1.4.200 version. Need just some syntax changes to th...
- 03:29 PM Support #4701: try to improve H2 transaction commit performance
- Adrian, this performance data presents an interesting counterpoint to the information posted previously to #4057. Ple...
- 11:26 AM Support #4701: try to improve H2 transaction commit performance
- I have done some testing using the Apache JMeter in order to see some differences between H2 versions: 1.4.196, 1.4.1...
- 04:14 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Ovidiu Maxiniuc wrote:
> > * @TypeManager.setFwdDatetimetzParameter()@ you decided not ... - 04:05 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Review for 4011b rev 11537:
> * in which cases in @FqlToSqlConverter.getSqlColumnAlias@, t... - 04:00 PM Feature #4011: database/persistence layer performance improvements
- Review for 4011b rev 11537:
* in which cases in @FqlToSqlConverter.getSqlColumnAlias@, the @sqlName@ is null col "co... - 03:36 PM Feature #4011: database/persistence layer performance improvements
- More blob, clob and datetimetz fixes are in 4011b rev 11537.
- 03:34 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> They have an id reserved in @ReservedProperty@, indeed.
In the DMO interface, the annotat... - 03:33 PM Feature #4011: database/persistence layer performance improvements
- They have an id reserved in @ReservedProperty@, indeed.
However, if I remember correctly, they are true fields in d... - 03:17 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu, is it normal for a before-table to explicitly generate the @_error-flag@, @_row-state@ and other related prop...
- 02:49 PM Feature #4011: database/persistence layer performance improvements
- I'm getting an NPE when checking in a guest in Hotel GUI:...
- 01:40 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> 4011b rev 11535 seems fine to me. It's really strange that PSQL dialect has so specials nee... - 01:23 PM Feature #4011: database/persistence layer performance improvements
- 4011b rev 11535 seems fine to me. It's really strange that PSQL dialect has so specials needs.
4011b rev 11536: one ... - 01:04 PM Feature #4011: database/persistence layer performance improvements
- 4011 rev 11536 has these:
* Ignore DMO properties like _error-flag, _row-state, etc, where only table-defined legacy... - 12:47 PM Feature #4011: database/persistence layer performance improvements
- 4011b rev 11535 completed implementation for blob, clob, comhandle, handle, object and raw field types. Please review.
- 12:47 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> This code in @TemporaryBuffer$Context.nextPrimaryKey@:
> [...]
OK, yes, I see now.... - 12:27 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> So, instead of @lte@, we should emit @tt1.f1 < ?@, and use @PreparedStatement.setTimesta... - 12:23 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> All our supported dialects have a field type which includes the time zone. However, they de... - 12:17 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Constantin Asofiei wrote:
> > Constantin Asofiei wrote:
> > > Ovidiu/Eric: when does a del... - 12:07 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Constantin Asofiei wrote:
> > Ovidiu/Eric: when does a deleted record get evicted from ... - 11:57 AM Feature #4011: database/persistence layer performance improvements
- Committed @DirtyShareSupport@ class missing from last commit, as 4011b rev 11534.
- 11:35 AM Feature #4011: database/persistence layer performance improvements
- All our supported dialects have a field type which includes the time zone. However, they decided to support them diff...
- 10:47 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu, in SQL, do we still need the '_offset' column when comparing a datetime-tz field with another (string represe...
- 09:02 AM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Ovidiu/Eric: when does a deleted record get evicted from the @orm.Session.cache@? I can'... - 08:42 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu/Eric: when does a deleted record get evicted from the @orm.Session.cache@? I can't find any place for this... ...
- 06:36 AM Feature #4011: database/persistence layer performance improvements
- I have committed 4011a_rebase rev 11533, which fixes the CAN-FIND in the test case from #4011-577 and enables dirty s...
- 04:01 PM Bug #4057: h2 performance degradation
- I've done a testing effort in comparing 1.4.196, 1.4.197, 1.4.197 patched, 1.4.198 and 1.4.199. I shared the results ...
- 01:39 PM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- FYI, 4011b is the branch for this work. 4011a and 4011a_rebase are now frozen.
07/01/2020
- 07:26 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Is it safe to change @getLegacyField2Name()@, to omit these properties?
I do not know e... - 07:24 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Is it safe to change @getLegacyField2Name()@, to omit these properties?
It seems that o... - 07:18 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Constantin Asofiei wrote:
> > Thanks, that solved this. And following is @TableMapper.leg... - 07:13 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Thanks, that solved this. And following is @TableMapper.legacyGettersByProperty@ - this... - 07:07 PM Feature #4011: database/persistence layer performance improvements
- Thanks, that solved this. And following is @TableMapper.legacyGettersByProperty@ - this doesn't include the @TempTab...
- 06:59 PM Feature #4011: database/persistence layer performance improvements
- The dataset-related fields are added to @DmoMeta@ only if the table has before/after tables declared (see @src/com/go...
- 06:40 PM Feature #4011: database/persistence layer performance improvements
- Thanks, that solve this one. Now moving to more @TempTableRecord@ properties. The failure is this:...
- 06:35 PM Feature #4011: database/persistence layer performance improvements
- Use this in @DmoMetadataManager@:375 (method @getExistingFields()@):...
- 06:24 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> In my opinion, we should set in @TempTableBuilder@:686:
> [...]
> and get rid of @columnT... - 06:20 PM Feature #4011: database/persistence layer performance improvements
- I am all for getting rid of multi-layer mappings; they slow things down and complicate code maintenance. But there ar...
- 06:18 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> What seems to me is that the @P2JIndexCompoent@ can be used with FQL and SQL style index... - 06:15 PM Feature #4011: database/persistence layer performance improvements
- I think the problem is the ambiguity of @P2JIndex@. It is a descriptor of an index, which may be either a Progress in...
- 06:10 PM Feature #4011: database/persistence layer performance improvements
- In 4011a_rebase the index component is built from the DMO interface:...
- 06:07 PM Feature #4011: database/persistence layer performance improvements
- That suggests to me that the @column@ attribute of the @@Property@ annotation on the DMO interface is wrong, and shou...
- 05:59 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Either, the column name key (i.e., the post-SQL-keyname-conflict-resolution version with the... - 05:49 PM Feature #4011: database/persistence layer performance improvements
- Either, the column name key (i.e., the post-SQL-keyname-conflict-resolution version with the trailing underscore) is ...
- 04:57 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> I have a new case of name mismatch in @TempTableBuilder.getExistingIndexes@.
>
> The ... - 04:45 PM Feature #4011: database/persistence layer performance improvements
- The recreate is this:...
- 04:16 PM Feature #4011: database/persistence layer performance improvements
- I have a new case of name mismatch in @TempTableBuilder.getExistingIndexes@.
The field name is @order@, @P2JIndexC... - 02:04 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> I need to find another way of creating the @PgBlob@ instance...
In the end, PostgreSQL ... - 11:56 AM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Ovidiu, please check Hotel GUI for any other issues with 4011a_rebase.
OK, I will focus... - 11:48 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Unless there is something more important I can help with. Please let me know.
Ovidiu, plea... - 10:33 AM Feature #4011: database/persistence layer performance improvements
- I found a possible issue in @DmoMetadataManager@, when tables from different databases have the same name.
I am not ... - 09:29 AM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> And now I'm stuck because we are using c3p0 (which has @com.mchange.v2.c3p0.impl.NewProx... - 09:18 AM Feature #4011: database/persistence layer performance improvements
- And now I'm stuck because we are using c3p0 (which has @com.mchange.v2.c3p0.impl.NewProxyConnection@ instances for @j...
- 08:46 AM Feature #4011: database/persistence layer performance improvements
- @BlobType.readProperty@ is like this:...
- 07:52 AM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Eric Faulhaber wrote:
> > Ovidiu, we are still converting LOBs for DMOs (interfaces and im... - 07:27 AM Feature #4011: database/persistence layer performance improvements
- First time I'm trying to fire up the FWD server with 4011_rebase (rev 11531), in order to run a test case. I get this...
- 02:47 AM Feature #4011: database/persistence layer performance improvements
- 4011a_rebase r11531 has modified build.gradle to use the fwd-h2 patched in this task, as ver 1.4.197-20200530.
- 08:12 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Ovidiu, we are still converting LOBs for DMOs (interfaces and implementation classes), it se... - 08:10 PM Feature #4011: database/persistence layer performance improvements
- About the 'reWriteBatchedInserts=true' optimization for data import. I think this is just reporting '0' after the in...
- 08:00 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu, we are still converting LOBs for DMOs (interfaces and implementation classes), it seems, same as before. What...
- 01:47 PM Support #4702: write temp-table performance test cases
- Looks good so far.
In addition to the OPEN QUERY use you have in the read tests, please add some stressful use of ... - 08:22 AM Support #4702: write temp-table performance test cases
- I've committed read and update testcases to @testcases/uast/h2_performance@. The remaining testcases will follow.
- 01:31 PM Feature #4723: make it significantly easier to run database import
- The database import should be very simple to run, but today it has some "sharp edges" which tend to trip people up. ...
- 01:21 PM Feature #4723 (New): make it significantly easier to run database import
- 01:18 PM Feature #4722: data import should be able to run with only the converted application jar file (an...
- The current approach has a fragile design which requires that we have a conversion project (or at least parts of it s...
- 01:15 PM Feature #4722 (Test): data import should be able to run with only the converted application jar f...
06/30/2020
- 07:58 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Constantin Asofiei wrote:
> > Some details about postgresql are here: https://jdbc.postgre... - 07:50 PM Feature #4011: database/persistence layer performance improvements
- There's a change in 4011a_rebase which breaks @RecordBuffer.initialize@. This was previously done when @getDMOImplem...
- 07:38 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Some details about postgresql are here: https://jdbc.postgresql.org/documentation/80/bin... - 07:29 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> blob and clob import is broken now. I'm working on fixing @PropertyMapper@.
The same p... - 07:09 PM Feature #4011: database/persistence layer performance improvements
- blob and clob import is broken now. I'm working on fixing @PropertyMapper@.
- 05:05 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> There are some issues in @IndexHelper.getPrimaryIndex@:
> * it was using @dmoClass@ ins... - 04:48 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Constantin Asofiei wrote:
> > * @TemporaryBuffer@
> > ** @makeMutable@ - yes, we need ... - 08:35 AM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> * @TemporaryBuffer@
> ** @makeMutable@ - yes, we need an interface there, otherwise the... - 05:43 AM Feature #4011: database/persistence layer performance improvements
- The patch looks ok to me.
- 08:04 PM Feature #4011: database/persistence layer performance improvements
- There are some issues in @IndexHelper.getPrimaryIndex@:
* it was using @dmoClass@ instead of @dmoIface@ to get the a... - 04:39 PM Feature #3814: more schema metadata
- Found a minor issue with @_Field-Trig@ population.
Committing to 3821c revision 11381. ... - 03:57 PM Feature #3814: more schema metadata
- Roger Borrello wrote:
> Igor Skornyakov wrote:
> > Very strange. Can you please send me your project? I will take a... - 03:24 AM Feature #3814: more schema metadata
- Roger Borrello wrote:
> Igor Skornyakov wrote:
> > Very strange. Can you please send me your project? I will take a... - 10:34 PM Feature #3814: more schema metadata
- Igor Skornyakov wrote:
> Very strange. Can you please send me your project? I will take a look tomorrow.
> Thank yo... - 02:14 PM Support #4702: write temp-table performance test cases
- It is a common case in which a lot of time is likely to be spent in real applications. Any server-side stuff is goin...
- 01:09 PM Support #4702: write temp-table performance test cases
- Greg Shah wrote:
> Perhaps it makes sense to have a test that has some temp-tables with large numbers of columns and... - 01:06 PM Support #4702: write temp-table performance test cases
- Stanislav Lomany wrote:
> [...]
> Is that good for a start?
Yes. - 08:58 AM Support #4702: write temp-table performance test cases
- I'm think there will be tables which will have the same set of fields:
# integer
# char
# double
# date
# logica... - 08:17 AM Support #4702: write temp-table performance test cases
- Perhaps it makes sense to have a test that has some temp-tables with large numbers of columns and uses buffer-copy to...
- 01:14 PM Feature #4055: optimize temp-table output parameter copying
- Constantin Asofiei wrote:
> Eric Faulhaber wrote:
> > * Pre-validation of each record is necessary. If we leave it ... - 06:00 AM Feature #4055: optimize temp-table output parameter copying
- Eric Faulhaber wrote:
> * Pre-validation of each record is necessary. If we leave it to the database to reject uniqu... - 06:02 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- Igor Skornyakov wrote:
> Is it a top-priority task?
It is next highest priority behind any work needed to complet... - 06:00 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- @TempTableDataSourceProvider@ was introduced in branch 4011a to provide database connections to the in-memory H2 data...
- 05:53 AM Bug #4703: investigate whether performance of TempTableDataSourceProvider can be improved
- Is it a top-priority task?
Thank you. - 05:50 AM Bug #4703 (Hold): investigate whether performance of TempTableDataSourceProvider can be improved
- 08:24 PM Support #4701: try to improve H2 transaction commit performance
- Eric Faulhaber wrote:
> Start with version 1.4.197 and apply our existing patches before you build. Constantin has a... - 08:22 PM Bug #4057: h2 performance degradation
- Eric Faulhaber wrote:
> Constantin has a recent patch which is not integrated into the FWD distribution yet; you wil...
06/29/2020
- 07:43 PM Support #4702: write temp-table performance test cases
- We need a set of temp-table related test cases in support of issues #4057 and #4071. The tests need to stress H2 as t...
- 05:11 PM Support #4702 (Closed): write temp-table performance test cases
- 07:16 PM Bug #4057: h2 performance degradation
- Please get the source for the latest version of H2 (1.4.200 at the time of this writing) and port our existing patche...
- 07:07 PM Support #4701: try to improve H2 transaction commit performance
- H2's transaction commit code repeatedly shows up as a performance bottleneck when profiling FWD application code. We ...
- 05:10 PM Support #4701 (Closed): try to improve H2 transaction commit performance
- 06:02 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu, there is a TODO in @TableMapper@:...
- 02:57 PM Feature #4011: database/persistence layer performance improvements
- @DmoMetadataManager.getBasePackage@
LE: Sorry, it's actually @DmoMetadataManager.getDmoBasePackage@, and it will i... - 02:52 PM Feature #4011: database/persistence layer performance improvements
- What is the counterpart of the @DMOIndex.getBasePackage()@ in 4011a?
Thank you. - 12:52 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Ovidiu Maxiniuc wrote:
> > Greg Shah wrote:
> > > Is index size a problem for temp-tables?... - 08:54 AM Feature #4011: database/persistence layer performance improvements
- * @SortCriterion@
** @WHERE_WITH_NULLS@ I think can be removed. I'll need to double-check the customer project, but... - 08:30 AM Feature #4011: database/persistence layer performance improvements
- @FWDDataObject@ - this class is used outside of the FWD context, by customer code via @LegacyJavaAppserver@. I'm wor...
- 07:52 AM Feature #4011: database/persistence layer performance improvements
- Regarding the rebase TODO in @DatabaseManager.getDatabaseDMOs@...
The javadoc for @DatabaseManager.getDatabaseDMOs... - 05:20 PM Feature #3814: more schema metadata
- Constantin Asofiei wrote:
> Roger, what version of 3821c do you have? Note that trunk had a metadata generation issu... - 05:17 PM Feature #3814: more schema metadata
- Roger, what version of 3821c do you have? Note that trunk had a metadata generation issue which was solved in a 3821...
- 05:08 PM Feature #3814: more schema metadata
- Roger Borrello wrote:
> Igor Skornyakov wrote:
> > Roger,
> > I'm busy now with some urgent assignment. Was the @m... - 05:03 PM Feature #3814: more schema metadata
- Igor Skornyakov wrote:
> Roger,
> I'm busy now with some urgent assignment. Was the @meta_table_ddl.sql@ file gener... - 04:48 PM Feature #3814: more schema metadata
- Roger Borrello wrote:
> I started receiving this during runtime of my testcase:
> [...]
>
> I made a few updates... - 04:38 PM Feature #3814: more schema metadata
- I started receiving this during runtime of my testcase:...
- 02:30 PM Feature #3814: more schema metadata
- 3821c revision 11377 fixes a regression DMO generation. The VIEW-AS text can have embedded quotes and escape sequenc...
- 11:40 PM Feature #3813: misc DB features part deux
- Branch 3821c revision 11374 has the implementation of @BUFFER-FIELD:DEFAULT-VALUE@ as well as the fixes to @date@/@da...
06/27/2020
- 04:13 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu Maxiniuc wrote:
> Greg Shah wrote:
> > Is index size a problem for temp-tables? I thought that was a SQLSer...
06/26/2020
- 07:33 PM Feature #4011: database/persistence layer performance improvements
- Greg Shah wrote:
> Is index size a problem for temp-tables? I thought that was a SQLServer thing.
4GL has its own ... - 07:27 PM Feature #4011: database/persistence layer performance improvements
- Is index size a problem for temp-tables? I thought that was a SQLServer thing.
- 06:55 PM Feature #4011: database/persistence layer performance improvements
- Note that in the cases where the DMO implementation classes are different, it is not just unique constraints that are...
- 06:36 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> Constantin Asofiei wrote:
> > In @TemporaryBuffer.copyAllRows@, we can skip record validati... - 06:13 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> In @TemporaryBuffer.copyAllRows@, we can skip record validation if:
> [...]
>
> This...
06/25/2020
- 04:10 PM Feature #3814: more schema metadata
- Added _File-Trig and _Field-Trig population
Committing to 3821c revision 11366. ... - 12:51 PM Feature #4011: database/persistence layer performance improvements
- Regarding the test at #4011-633 - I've created a physical database with the same table structure and indexes, and OE ...
- 12:49 PM Feature #4011: database/persistence layer performance improvements
- Eric Faulhaber wrote:
> I'm not sure what you are asking. Across different DMO implementation classes, two unique in... - 12:44 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> But, does anyone know if we have a way to check if the unique indexes in two DMO impl ma... - 09:55 AM Feature #4011: database/persistence layer performance improvements
- For temp-tables, FWD has problems with this test:...
- 09:10 AM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Eric, an idea about the temp-table flushing. We currently save on every touched field. ... - 09:00 AM Feature #4011: database/persistence layer performance improvements
- Eric, an idea about the temp-table flushing. We currently save on every touched field. But I think we can defer thi...
- 06:36 AM Feature #4011: database/persistence layer performance improvements
- In @TemporaryBuffer.copyAllRows@, we can skip record validation if:...
06/24/2020
- 06:49 PM Feature #4011: database/persistence layer performance improvements
- The NULLS LAST/FIRST fix is in 4011a rev 11499.
- 05:50 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> I don't understand what is happening. The same SQL in the standalone H2 server knows to... - 03:29 PM Feature #4011: database/persistence layer performance improvements
- I don't understand what is happening. The same SQL in the standalone H2 server knows to move the nulls to last posit...
- 02:35 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Also, H2 is wrong with or without a DESC index for F2 - the NULL must be first.
To be m... - 02:33 PM Feature #4011: database/persistence layer performance improvements
- Ovidiu, add an ASC index for F1 and you will see that H2 is wrong - it will place the NULL first.
Also, H2 is wron... - 02:32 PM Feature #4011: database/persistence layer performance improvements
- ...
- 02:28 PM Feature #4011: database/persistence layer performance improvements
- What's the result for @select * from t1 order by f1 desc;@?
- 02:27 PM Feature #4011: database/persistence layer performance improvements
- I did a quick test with H2:...
- 02:24 PM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> I have some tests, and OE sorts the nulls always last, regardless of direction.
Sorry, ... - 02:01 PM Feature #4011: database/persistence layer performance improvements
- I have some tests, and OE sorts the nulls always last, regardless of direction.
H2 has a bug in that it doesn't co... - 01:16 PM Feature #4011: database/persistence layer performance improvements
- Postgresql states that:
> By default, null values sort as if larger than any non-null value; that is, NULLS FIRST is... - 11:48 AM Feature #4011: database/persistence layer performance improvements
- Constantin Asofiei wrote:
> Another issue is that the SUBSELECT doesn't have the @NULLS LAST@. At least we should b... - 11:42 AM Feature #4011: database/persistence layer performance improvements
- There is a problem in 4011a, where we emit @NULLS LAST@ in the @ORDER BY@ clause. This causes a performance regressi...
- 03:20 PM Feature #3814: more schema metadata
- Finished with VIEW-AS field property conversion and population of the @_Field._View-As@.
Tested with a standalone te... - 08:55 AM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Roger Borrello wrote:
> Constantin Asofiei wrote:
> > Roger, the fix is in 3821c rev 11363.
> >
> > Please test ... - 08:40 AM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Constantin Asofiei wrote:
> Roger, the fix is in 3821c rev 11363.
>
> Please test with the customer scenario.
... - 07:10 AM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Roger, the fix is in 3821c rev 11363.
Please test with the customer scenario. - 05:58 AM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Eric Faulhaber wrote:
> I am attaching a patch because I didn't have a branch to which to commit. The attached patch... - 05:28 AM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Eric Faulhaber wrote:
> Constantin, please take it from here.
OK, I'm working on it.
- 01:33 AM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Roger Borrello wrote:
> That patch alleviated the NPE, and we now result in:
> * "Unable to PREPARE TEMP-TABLE bu... - 07:05 AM Support #3871: determine how to change codepages/locales during import
- This task is not about the runtime environment. This is only about database import.
What matters is that we must ... - 12:02 AM Support #3871: determine how to change codepages/locales during import
- Analyzing the task history. The @FWD@ functionality from my understanding is to have tow separate parts, runtime envi...
06/23/2020
- 07:54 PM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Eric Faulhaber wrote:
> Yes and no :-)
>
> I am attaching a patch because I didn't have a branch to which to comm... - 06:09 PM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Yes and no :-)
I am attaching a patch because I didn't have a branch to which to commit. The attached patch fixes ... - 06:04 PM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Eric Faulhaber wrote:
> Nevermind, got it.
Are you looking at this? Did you see the notes in #4208-736 ? - 04:55 PM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Nevermind, got it....
- 04:49 PM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Stack trace?
- 04:01 PM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- Will there be different code-paths for a temp-table versus a standard table? I am walking through the testcase, tryin...
- 01:17 PM Bug #3172: QUERY-PREPARE can be used on static queries (and the sorting can be dynamically changed)
- This code generates a @NPE@ on @trunk-11347@:...
- 07:17 PM Feature #4011: database/persistence layer performance improvements
- I committed revision 11496 to 4011a. It is mainly a FLQ support update:
* added support for DMOs in FROM clause of S... - 10:35 AM Feature #4011: database/persistence layer performance improvements
- It is not clear to me why we match @PROPERTY@ in the lexer (as @DOT SYMBOL@). Since there are many possible qualifie...
- 10:22 AM Feature #4011: database/persistence layer performance improvements
- Related to parsing of FQL: at this moment FQL2SQL is unable to parse queries like:
@from com.goldencode.appname.dmo.... - 06:06 AM Feature #4011: database/persistence layer performance improvements
- I've committed revisions 11494 and 11495. 11494 is Ovidiu's import fix. 11495 partially fixes the test case in #4011-...
- 05:38 PM Feature #3814: more schema metadata
- After adding checks for @null@ to the @SymbolResolver@ I do not see warning anymore and there is a @KW_VIEW_AS@ note...
- 05:12 PM Feature #3814: more schema metadata
- > I do not see KW_VIEW_AS node in the .schema or .dict files. Maybe this is a result of NPE.
Yes, possibly so. - 05:04 PM Feature #3814: more schema metadata
- Greg Shah wrote:
> > however, there is no KW_VIEW_AS node in the AST at all
>
> The @replaceAst()@ rewrites that ... - 04:46 PM Feature #3814: more schema metadata
- > however, there is no KW_VIEW_AS node in the AST at all
The @replaceAst()@ rewrites that @KW_VIEW_AS@ subtree, th... - 04:42 PM Feature #3814: more schema metadata
- Greg Shah wrote:
> Constantin Asofiei wrote:
> > Greg, do you think is safe to set @dict=true@ at the @SymbolResolv... - 04:37 PM Feature #3814: more schema metadata
- Constantin Asofiei wrote:
> Greg, do you think is safe to set @dict=true@ at the @SymbolResolver@ instance created b... - 04:10 PM Feature #3814: more schema metadata
- Constantin Asofiei wrote:
> Greg, do you think is safe to set @dict=true@ at the @SymbolResolver@ instance created b... - 03:39 PM Feature #3814: more schema metadata
- Greg, do you think is safe to set @dict=true@ at the @SymbolResolver@ instance created by @SchemaLoader.postProcessIm...
- 03:36 PM Feature #3814: more schema metadata
- Constantin Asofiei wrote:
> Igor Skornyakov wrote:
> > This is exactly what I did. It seems that not callers are re... - 03:24 PM Feature #3814: more schema metadata
- Igor Skornyakov wrote:
> This is exactly what I did. It seems that not callers are ready for @null@. But I will try ... - 03:19 PM Feature #3814: more schema metadata
- Constantin Asofiei wrote:
> > I've tried this. It doesn't help, NPE happens in @SymbolResolver.addWrappedWorker@
> ... - 03:15 PM Feature #3814: more schema metadata
- Igor Skornyakov wrote:
> Constantin Asofiei wrote:
> > I think is enough to add a NPE check there for @currentCls@.... - 03:13 PM Feature #3814: more schema metadata
- Constantin Asofiei wrote:
> I think is enough to add a NPE check there for @currentCls@. During schema parser, ther... - 03:08 PM Feature #3814: more schema metadata
- Igor Skornyakov wrote:
> The conversion of the .df files produces a number of warnings like this:
> [...]
> This h... - 02:59 PM Feature #3814: more schema metadata
- The conversion of the .df files produces a number of warnings like this:...
- 08:01 AM Support #3871 (WIP): determine how to change codepages/locales during import
- Sergey Ivanovskiy wrote:
> I used the similar diff to the following one in order to setup the UTF-8 database with IN...
Also available in: Atom