> This sort of surprises me, but maybe it makes sense to those who
> understand what Entity Modeler is doing behind the scenes.
It does, and I'll explain it :)
> First, I had to add the JavaEOAccess framework to the framework's
> build path.
SQL Generation in Entity Modeler uses EOF. It does this in a sort of
tricky way. It actually takes the build path of your project and
constructs a new classloader using all of the jars in your build
path. It uses this classloader to load EOF and then execute the code
necessary to generate SQL in EOF. I'm actually not sure how your app
ran when you deployed it if you didn't include JavaEOAccess in your
build path? So while it's technically not required to BUILD your
project, it's required to RUN your project, so you should have already
had JavaEOAccess?
> A different exception was eliminated by adding the JavaJDBCAdaptor
> framework to the build path.
All the same reasons here.
> Yet another exception was eliminated by adding the FrontBase JDBC
> driver, frontbasejdbc.jar, to the build path.
... and here, except that generally people have frontbasejdbc.jar in /
Library/Java/Extensions and it should be picked up automatically. Do
you not have that?
> To eliminate another exception, I had to connect via VPN to the
> network on which the database host lives (I wonder why Entity
> Modeler must access the database itself to generate SQL).
Talk to your friendly neighborhood EOF about this one. EOModeler had
this same restriction except that it required you to be able to
connect to the database right from the start. If you notice, Entity
Modeler doesn't give you a list of external types like EOModeler did.
That's because I didn't want to require that you had to have access to
your database just to make a model (like EOM required to get
jdbc2Info). However, I can't escape it for SQL gen ... EOF has to be
able to fire up a connection to get jdbc2Info to be able to get
external types. I've always felt this was stupid. The plugins SHOULD
be able to return their external type information without a db
connection, but I suppose you could argue that external types could
change across versions, but it's perfectly acceptable to me that you
have to update your plugin if you update your db version. I've
actually been considering this with the FrontBasePlugIn and PG plugin,
to add a feature where it just has its
external type info hardcoded in the plugin so it doesn't require this.
In your particular case, you could setup a second database config for
a local FrontBase db, at least, and generate SQL off of that.
> I never experienced the above exception. Is something wrong with
> the eomodel's connection dictionary?
I was suspecting the same.
ms
This archive was generated by hypermail 2.0.0 : Sun Mar 09 2008 - 13:18:49 EDT