Bug #2237
wrong historical annotations in dynamic temp-tables
100%
History
#1 Updated by Ovidiu Maxiniuc over 10 years ago
- Status changed from New to WIP
When creating dynamic temp-tables the field and table annotations are wrong. I could reproduce this in dynamic queries (methods find-first etc). The code:
create temp-table dt1.
dt1:add-new-field("booK-id", "integer").
dt1:add-new-field("iSbn", "character").
dt1:temp-table-prepare("tFile").
is converted in-memory at runtime to an AST like:
_temp [DATA_MODEL] @0:0
(package=com.goldencode.p2j.persist.dynamic, path=com/goldencode/testcases/dmo/, permanent=false, peerid=1)
DynamicRecord1 [CLASS] @0:0
(peerid=2, historical=dtt1, table=dtt1)
id [PRIMARY] @0:0
(column=id, datatype=Long)
field1 [PROPERTY] @0:0
(peerid=3, column=field1, historical=field1, datatype=integer, label=booK-id, fieldid=1)
initial [INITIAL] @0:0
0 [NUM_LITERAL] @0:0
field2 [PROPERTY] @0:0
(peerid=4, column=field2, historical=field2, datatype=character, label=iSbn, length=256, fieldid=2)
initial [INITIAL] @0:0
[STRING] @0:0
The historical annotations are wrong (original values are lost), so they cannot be found later when needed by dynamic queries in P2OLookup.
#2 Updated by Ovidiu Maxiniuc over 10 years ago
Here is a more complex sample case:
def var h1 as handle.
def var h2 as handle.
def var bh1 as handle.
def var bh2 as handle.
create temp-table h1.
h1:add-new-field("F-1", "character").
h1:temp-table-prepare("T#t").
bh1 = h1:default-buffer-handle.
create temp-table h2.
h2:add-new-field("I#1", "integer").
h2:temp-table-prepare("T#t").
bh2 = h2:default-buffer-handle.
...
bh1:find-first().
bh2:find-first().
Thanks to Stanislav for suggestion, I am working with this case, too.
#3 Updated by Ovidiu Maxiniuc over 10 years ago
- File om_upd20140128a.zip added
Looks like this update fixes the issue.
The table legacy name is also added to in-memory AST. When TRPL (p2o.xml) is about to update the "historical" annotation for table/field/index, first it checks is there is not one in [this]. This will only happen for dynamic temp-tables so it will use that value, otherwise will save in this annotation the object name as it will be overwritten.
I was just about to send this note when I saw a
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:806)
at java.util.HashMap$KeyIterator.next(HashMap.java:841)
at com.goldencode.p2j.persist.DynamicTablesHelper$Context.finished(DynamicTablesHelper.java:854)
I have fixed that (see DynamicTablesHelper.java:858) before uploading the update.
#4 Updated by Eric Faulhaber about 10 years ago
I have fixed that (see DynamicTablesHelper.java:858) before uploading the update.
Why not use java.util.Set's <T> T[] toArray(T[] a) method here instead of doing the cast?
Otherwise, the update looks good.
#5 Updated by Ovidiu Maxiniuc about 10 years ago
No 'strong' reason. Looking into AbstractCollection's source code, both methods share the same implementation except for the initial step of creating the returning array if its size is incorrect.
I will replace the method body with
Set<Class> keys = tables.keySet();
Class[] classes = new Class[keys.size()];
classes = keys.toArray(classes); // should return the same array object
for (Class dmoIface : classes)
{
instance.dropTable(dmoIface);
}
Semantically, it's the same. I will put this new update to a full-test.
#6 Updated by Eric Faulhaber about 10 years ago
Ovidiu, please post the final update you used for testing and check it in and distribute once it has passed.
#7 Updated by Ovidiu Maxiniuc about 10 years ago
- File om_upd20140214a.zip added
This is the latest update that is not under testing.
It passed the conversion (I had to manually run the diff - there were no changes in generated code), however I am encountering difficulties with runtime test, not because of the code itself but seems like the server is a little overloaded as I got these exceptions a few times now:
[exec] Non-testing errors (CONNECT_FAILURE) occured during test execution:
[exec] com.jcraft.jsch.JSchException: Auth fail
[exec] at com.jcraft.jsch.Session.connect(Session.java:502)
[exec] at com.goldencode.harness.transport.SSH2Transport.connect(SSH2Transport.java:70)
[exec] at com.goldencode.harness.transport.TransportManager.connect(TransportManager.java:69)
[exec] at com.goldencode.harness.Driver.<init>(Driver.java:83)
[exec] at com.goldencode.harness.TestSet.run(TestSet.java:257)
[exec] at java.lang.Thread.run(Thread.java:744)
for both CTRL+C and main test suites.
In the worse case, I will try again tomorrow.
#8 Updated by Eric Faulhaber about 10 years ago
Ovidiu, you modified p2o.xml and conversion testing has passed. The only other files that changed are new runtime classes that are not used by the regression testing environment, so I would not worry about runtime regression testing. If you are satisfied that this update fixes the issue, go ahead and check it in and distribute.
Before you do this, please correct the module name at the top of DynamicTablesHelper, which says P2JField.java.
#9 Updated by Ovidiu Maxiniuc about 10 years ago
- File deleted (
om_upd20140214a.zip)
#10 Updated by Ovidiu Maxiniuc about 10 years ago
- File om_upd20140214b.zip added
Replaced the update with the new one with the small change.
It was committed to bzr in rev 10465 and distributed by mail.
#11 Updated by Eric Faulhaber about 10 years ago
- % Done changed from 0 to 100
- Status changed from WIP to Closed
#12 Updated by Greg Shah over 7 years ago
- Target version changed from Milestone 11 to Cleanup and Stablization for Server Features