Hi Susan,
Thanks for a very elaborate answer. I'll try to answer your questions inline.
Susan Cline wrote:
Hi Thomas,
I'm a little bit confused about your questions, so I'll ask some
questions and hopefully you can help me understand what you are trying
to do.
Let me state what I know about the Derby plug-in right now to help clarify:
1) From an application developers point of view the Derby jar files can
be added to individual projects in a workspace either "manually" using
just the Derby core plug-in, or automatically using the Derby UI plug-in
via a menu item.
2) From an application developers point of view a Derby database that is
created via the url "jdbc:derby:myDB;create=true" is added to the
project in the workspace where the derby jar files where added.
3) A derby database can be created using a full file system path. In
other words, the database does not have to be created relative to a
directory - a full system path can be specified.
OK, all of this is clear to me.
Now, regarding your comments and questions:
When you say "the embedded system is configured to use one single root
where all databases are stored" - are you referring to your plug-in as
the "embedded system"? I'm not sure what you mean as the embedded system.
Can you elaborate what you mean by this statement:
"If my plugin defines this property to some location (say the state
location for the plugin), it will make it impossible to other plugins
that also wish to use Derby in the same Eclipse instance."
When you say impossible to other plugins that wish to use Derby in the
same Eclipse instance do you mean the same Derby database? Is this
Derby database used to store metadata for the plug-in or is it an
application database?
The former. Some of the plugins make use of rather complex meta-data and I want to use derby
databases to store this meta-data. Transaction stability etc. is of great importance.
So are you saying that all plug-ins that use the Derby plug-in for
metadata for their plug-ins should store databases in t he Derby plug-in
state directory?
Following the Derby recommendations, that would be the case. This might be a special case
where it would be appropriate for each plugin to have their databases in their own state
location so that the databases would be deployed/undeployed automatically together with the
plugin that owns it. I know to little about Derby to see the ramifications of that though.
Any advice is greatly appreciated.
Also, you mentioned this "root" is on a per JVM basis. As you probably
know if you are using an embedded Derby database, only one JVM can
access this database at one time. I'm not sure if this is relevant to
what you are talking about or not.
It is. The Eclipse instance (whether it's the Eclipse IDE or an Eclipse RCP app) is run by
one JVM but it might have several plugins that make use of Derby databases for meta-data.
Regarding the need for a more elaborate Derby plug-in is your desire for
the Derby plug-in to specify the derby.system.home to be the state
directory of the Derby plug-in, for all derby databases created from
within the Eclipse JVM?
Yes!
If so, this capability does not exist with the current plug-ins.
Would you be interested in publishing such a plugin? It would expose the derby packages
(short of the internal ones) so that other plugins may express a normal plugin dependency.
It would define the Derby system root and perhaps add some relevant extension points (not
sure what they would do just yet though). The current derby nature would not be used since
it seems targeted at application development. Some effort could be made to keep it mean and
lean since only the embedded driver would be of interest.
Eclipse plugins, created by different entities in different parts of the world must be able
to coexist. Hence I think it's important to publish a 'canonical' way of sharing a Derby
System (I'm sure I'm not the only one that has come up with the idea of using Derby for
meta-data). A collision between different ways of doing this is bound to happen sooner or
later otherwise.
It's essential that such a plugin exists and that it is published by a well known entity
(such as db.apache.org or eclipse.org) so that people will find it and understand what it's for.
Kind regards,
Thomas Hallgren
