[reporter="stephan", created="Thu, 29 Jan 2009 14:11:52 -0500 (GMT-05:00)"]
Provide a mechanism to delay transaction start until an operation requires it.

This is useful, for instance, for Farrago where FarragoDbSession.commitImpl() begins a transaction, calls FarragoSessionIndexMap.onCommit() and then commits the transaction. FarragoSessionIndexMap often performs no work (because no temporary tables were in use). When running against MySQL the begin/end transaction pair causes packets to be needlessly sent to the server. In this case, one solution could be to check for work before beginning the transaction, but it is possible to detect this condition in Enki itself.

The necessary work is to modify HibernateMDRepository.beginTrans() to defer creation of the Hibernate transation. Then, all of the HibernateMDRepository and JMI methods that could require a transaction must be modified to detect the deferred transaction and create the transaction before doing any work. For example, getByMofId() should perform the test. So should HibernateRefClass.refAllOfClass/Type. There are certainly others. Finally, the endTrans() methods should detect a deferred and never-started transaction and handle it properly.

[reporter="stephan", created="Mon, 1 Dec 2008 14:40:12 -0500 (GMT-05:00)"]
Regenerate JMI implementation classes and verify no significant changes have been made.

At the same time it would be useful to make this generation step a target in some Ant build file (perhaps something separate from build.xml) to make future updates easier.

[reporter="ngoodman", created="Fri, 31 Jul 2009 15:31:34 -0500 (GMT-05:00)"]
LucidDB 0.9.1 Analyzing statistics on TPCH tabels yields the following exception:

6/13 ANALYZE TABLE NATION ESTIMATE STATISTICS FOR ALL COLUMNS;
Error: org.eigenbase.sql.parser.SqlParseException: net.sf.farrago.HibernateOneToManyLazyOrderedAssociation.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; (state=,code=0)
Aborting command set because "force" is false and command failed: "ANALYZE TABLE NATION ESTIMATE STATISTICS FOR ALL COLUMNS;"

Restarting the server and running the same analyze statements yields perfect runs. I experienced this once before but I don't recall the circumstance.

[reporter="stephan", created="Mon, 22 Sep 2008 16:31:02 -0500 (GMT-05:00)"]
Sporadic build failures when using Sun JDK.

Investigate why it sometimes fails using Sun JVM. Associated bug is the occassional error where a class is not found (even happens with JRockit).

Perhaps the output of the code generation in forked JVM isn't finished before we try to compile (?!).

[reporter="stephan", created="Fri, 5 Dec 2008 18:58:33 -0500 (GMT-05:00)"]
Attribute and Associations are generated in different orders across JVMs.

Attribute parameter ordering in factory methods for class proxies vary across JVMs. This happens intermittently. See IceCreamCone references in ENK-3. In general, this likely means the Attributes are varying in order as well. It should only be visible for a) the factory methods already mentioned, and b) for event ordering for Attributes with a type that is a Classifier from the model itself.

Associations are generated in varying orders across JVMs as well. This happens more regularly and causes the MdrEventApiTest failure seen with the Sun JDK -- the eem.sample.special.Floor is firing events in order of associations found in the model and since the test requires it to fire events for two associations, reversing them causes the exception. (Also noted in ENK-3.)

Paths of investigation:
- Is this caused by XSLT output variation across JVMs? If so, is the variation unexpected (e.g., is the re-ordering ordered elements in the XML an XSLT script or XSLT processor bug) or expected (in which case can XSLT be modified to maintain order or should code gen sort the objects)
- If XMI input is constant, is MDR re-ordering elements that it shouldn't or is it Enki code gen?

[reporter="jvs", created="Fri, 28 Nov 2008 04:42:53 -0500 (GMT-05:00)"]
See disabled testCompositionAttributes in AttributeTest.

I encountered this in UML, where

StructureFeature = AbstractComposedElement
Attribute = ConcreteComposedElement
Multiplicity = CompositeElement

[reporter="jvs", created="Sat, 16 Aug 2008 21:52:41 -0500 (GMT-05:00)"]
So far I have only been able to hit this on tikki01-red using Sun JDK 1.5.0_09 (and even then only intermittently), probably due to order non-determinism in the XMI export used by JmiMemTest. But I think XmiFileComparator needs to protect itself against chasing reference cycles.

Testsuite: net.sf.farrago.test.JmiMemTest
Tests run: 8, Failures: 0, Errors: 1, Time elapsed: 33.162 sec

Testcase: testClassValuedAttributes took 0.654 sec
Testcase: testEarlyBinding took 0.125 sec
Testcase: testBreakOneToOneAssoc took 0.092 sec
Testcase: testExportImport took 0.341 sec
Testcase: testMassiveExportImport took 24.417 sec
        Caused an ERROR
null
java.lang.StackOverflowError
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:434)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:507)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:481)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:467)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:507)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:481)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:507)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:481)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:467)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:507)
        at org.eigenbase.enki.test.XmiFileComparator$ElementComparator.compare(X
miFileComparator.java:481)