Dynamic objects

[Gordan Vosicki <go...@icsa.ch>]

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