OK, so the problem is that the SQL Generation does not pickup prototype "cascading".
I had supplementary prototypes in the model "EOJDBCMySQLlistsourcePrototypes", and when selected in the "Default" connection, EntityModeler will actually display a combination of these supplementary prototypes *AND* ERPrototypes (auto selected from the jdbc URL it seems). However SQL Generation will *only* use the *one* prototypes list selected in the Default connection. This definitely does not seem like the correct behaviour? I would expect that SQL generation would draw from whatever list of prototypes that EntityModeler displays in the proto drop down list while building the EOModel.
So the workaround right now, if you want SQL generation, is not to add "additional supplementary" prototypes (even though ERXModel supports this at runtime), but just to copy the entire set of relevant prototypes from ERPrototypes, copy to your model (or wherever) and name the proto entity in such a way that ERXModel will prioritize it at runtime (see ERXModel javadoc). That seems to be the only way to have a EntityModeler drop down list that is consistent with SQL generation and runtime behaviour.
Mike, should I do a JIRA for this, or is it really something too awkward to be worthwhile, especially while the community is in the WO 5.3.3 to WO 5.4.3 never-ending transition?
Regards, Kieran
On Mar 1, 2010, at 9:09 AM, Kieran Kelleher wrote:
> Hi guys,
>
> I am getting NPE when generating SQL in EntityModeler.
>
> java.lang.RuntimeException: Failed to generate SQL.
> at org.objectstyle.wolips.eomodeler.core.sql.EOFSQLGeneratorFactory$ReflectionSQLGenerator.generateSchemaCreationScript(EOFSQLGeneratorFactory.java:67)
> at org.objectstyle.wolips.eomodeler.actions.GenerateSQLDialog.generateSql(GenerateSQLDialog.java:298)
> at org.objectstyle.wolips.eomodeler.actions.GenerateSQLDialog$1.run(GenerateSQLDialog.java:279)
> at java.lang.Thread.run(Thread.java:637)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.objectstyle.wolips.eomodeler.core.sql.EOFSQLGeneratorFactory$ReflectionSQLGenerator.generateSchemaCreationScript(EOFSQLGeneratorFactory.java:65)
> ... 3 more
> Caused by: java.lang.NullPointerException
> at com.webobjects.jdbcadaptor.JDBCExpression.columnTypeStringForAttribute(JDBCExpression.java:286)
> at com.webobjects.eoaccess.EOSQLExpression.addCreateClauseForAttribute(EOSQLExpression.java:2498)
> at com.webobjects.eoaccess.EOSynchronizationFactory.createTableStatementsForEntityGroup(EOSynchronizationFactory.java:318)
> at com.webobjects.eoaccess.EOSynchronizationFactory.createTableStatementsForEntityGroups(EOSynchronizationFactory.java:487)
> at com.webobjects.eoaccess.EOSynchronizationFactory.schemaCreationStatementsForEntities(EOSynchronizationFactory.java:951)
> at com.webobjects.eoaccess.EOSynchronizationFactory.schemaCreationScriptForEntities(EOSynchronizationFactory.java:747)
> at org.objectstyle.wolips.eomodeler.core.sql.EOFSQLGenerator53.generateSchemaCreationScript(EOFSQLGenerator53.java:483)
> ... 8 more
>
> I am guessing that the NPE would seem to indicate that I have a missing external type field on one of the attributes, but as you can see in this pic, all external types are resolved to prototypes. By any chance would using uncommon INT types such as TINYINT, SMALLINT, MEDIUMINT be causing this problem? ... or might this be something else? WO version is 5.3.3, WOlips 3.5.latest.
>
> http://idisk.me.com/kelleherk/Public/Pictures/Skitch/leads-20100301-090150.jpg
>
>
> Any ideas?
>
> Kieran
This archive was generated by hypermail 2.0.0 : Mon Mar 01 2010 - 09:45:38 EST
