Hi Andy,
There's been a lot of thinking about this since my last mail and I've come to
the conclusion that for my needs it will probably be better to use a standard
(possibly in-core) RDBMS and use the various callbacks to update the CAD
attributes in the CAD objects, or create or delete them, so I won't need a
custom datastore implementation.
There is however another gray zone: dynamic behavior. There is one use case
where I get a model description (in form of an ECore EMF model) and would like
to use the dynamic EObject implementation, which basically stores all object
fields in an array and has one getter and one setter, with the field ID as a
parameter. A pre-enhanced class could probably do the switching job between the
StateManager's view (field numbers) and the EMF view (attribute/reference id's).
There is however an issue in the fact that all objects have the same Java class
and only have an eClass() method which returns the "real" EMF class, and I
suspect datanucleus to rely strongly on this class to decide what to do about an
object, fetch metadata, etc, etc. Of course, one could create at runtime new
"real" subclasses just to have pc.getClass() return different values (and this
still does not solve everything), but I would prefer to have a pluggable
mechanism to get class metadata / class name for an object, rather than relying
on "getClass()", having an optional class resolver property in the PMF, or
something like this.
Do you have a feeling about the feasability of this approach (i.e. how many
changes should be done to implement it everywhere where needed in the code and
could it be integrated in the "mainstream" code) ?
Regards,
Gordan
Andy Jefferson wrote:
Hi Gordon,
A long time ago (2000 !), I wrote a partial implementation of the JDO 1.0
draft spec to make sure the application uses an object API (and not just
raw JDBC); the application still runs, but now uses datanucleus.
Now, after a long period of inactivity in the JDO field, I've got to write
an exotic datastore plugin
where the data objects are stored as CAD drawable (or not) objects residing
in a CAD drawing
and where the object properties are CAD attributes of the CAD objects.
Is there a document giving guidelines about the implementation of a new
datastore for datanucleus,
or should I better start with something roughly similar (maybe excel) or do
you have the feeling it
would be better to start from scratch ?
Well there is a very basic document
http://www.datanucleus.org/documentation/development/new_store_plugin_howto.html
but it only really touches the surface on what you'll need to do. I'd
definitely start from scratch but copy in features (from the most similar
plugin, excel? odf?) as you need them.
It comes down to what capabilities your datastore has, in terms of schema
generation (some of the plugins provide this), or in-datastore querying
(again, some do like Cassandra, MongoDB ... but others such as Excel, ODF
don't), etc.
Feel free to ask questions if you get stuck
Maybe later on in your experiences you can contribute an update to that
document based on what you found in doing it
Regards
