Hi Thomas,
You're welcome - thanks for your responses. I've cut out some of our discussions and tried to leave the relevant pieces with a few responses
in italics.
I think what you are asking for is a valid request. Could you file a JIRA request for this as an enhancement to the Derby plug-ins?
(Sorry if the formatting of this message is odd - for some reason I'm having a problem with my email client.)
Regards,
Susan
Thomas Hallgren <[EMAIL PROTECTED]> wrote:
Hi Susan,
Thanks for a very elaborate answer. I'll try to answer your questions inline.
Susan Cline wrote:
> 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.
Agreed - this is a great use of Derby in the Eclipse environment.
> 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 w ith the
plugin that owns it. I know to little about Derby to see the ramifications of that though.
Any advice is greatly appreciated.
I can understand what you mean here, and I'm not sure about the best way to handle it either. If the database was part of the "client" plug-in, the plug-in that depended on the derby plug-in, then removing that client plug-in would also remove the database which would be a clean way to do it. But on the other hand I'm not sure if this would work from a standpoint of Derby - if the Derby plug-in were to load the derby jar file I think this would not work, because only one derby.system.home would be available for the multiple plug-ins that relied on derby.jar. In this case, derby.system.home would need to be in the derby plug-ins state directory.
I would think that the "client" plug-in would have to be responsible for removing the derby database from derby.system.home if there was an "uninstall" option for the plug-in - or something where you could "clean-up" when you removed the plug-in.
Does that make sense?
> 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
I agree that this would be useful to plug-in developers. It seems like it might be possible to modify the core plug-in to perform some of these tasks. I'm not sure if we would want to have a Derby plug-in that would just consist of the derby.jar and do the tasks you mentioned above, or if we could just modify the existing derby core plug-in.
Please file a JIRA with your thoughts so if someone has the desire to change the derby plug-in(s) your input is taken into account.
(such as db.apache.org or eclipse.org) so that people will find it and understand what it's for.
Kind regards,
Thomas Hallgren
You're welcome - thanks for your responses. I've cut out some of our discussions and tried to leave the relevant pieces with a few responses
in italics.
I think what you are asking for is a valid request. Could you file a JIRA request for this as an enhancement to the Derby plug-ins?
(Sorry if the formatting of this message is odd - for some reason I'm having a problem with my email client.)
Regards,
Susan
Thomas Hallgren <[EMAIL PROTECTED]> wrote:
Hi Susan,
Thanks for a very elaborate answer. I'll try to answer your questions inline.
Susan Cline wrote:
> 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.
Agreed - this is a great use of Derby in the Eclipse environment.
> 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 w ith the
plugin that owns it. I know to little about Derby to see the ramifications of that though.
Any advice is greatly appreciated.
I can understand what you mean here, and I'm not sure about the best way to handle it either. If the database was part of the "client" plug-in, the plug-in that depended on the derby plug-in, then removing that client plug-in would also remove the database which would be a clean way to do it. But on the other hand I'm not sure if this would work from a standpoint of Derby - if the Derby plug-in were to load the derby jar file I think this would not work, because only one derby.system.home would be available for the multiple plug-ins that relied on derby.jar. In this case, derby.system.home would need to be in the derby plug-ins state directory.
I would think that the "client" plug-in would have to be responsible for removing the derby database from derby.system.home if there was an "uninstall" option for the plug-in - or something where you could "clean-up" when you removed the plug-in.
Does that make sense?
> 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
I agree that this would be useful to plug-in developers. It seems like it might be possible to modify the core plug-in to perform some of these tasks. I'm not sure if we would want to have a Derby plug-in that would just consist of the derby.jar and do the tasks you mentioned above, or if we could just modify the existing derby core plug-in.
Please file a JIRA with your thoughts so if someone has the desire to change the derby plug-in(s) your input is taken into account.
(such as db.apache.org or eclipse.org) so that people will find it and understand what it's for.
Kind regards,
Thomas Hallgren
