You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by "Andy Jefferson (JIRA)" <ji...@apache.org> on 2015/06/12 14:46:01 UTC
[jira] [Closed] (JDO-719) JDOQL should support Date.getDate instead
of Date.getDay
[ https://issues.apache.org/jira/browse/JDO-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Jefferson closed JDO-719.
------------------------------
> JDOQL should support Date.getDate instead of Date.getDay
> --------------------------------------------------------
>
> Key: JDO-719
> URL: https://issues.apache.org/jira/browse/JDO-719
> Project: JDO
> Issue Type: Bug
> Components: specification, tck
> Affects Versions: JDO 3.1-rc1
> Reporter: Michael Bouschen
> Assignee: Michael Bouschen
> Fix For: JDO 3.1-rc1
>
> Attachments: JDO-719.patch
>
>
> JDO-658 proposed support for more methods in JDOQL.
> It's clear reading the description of getDay that this is not the api that was intended. It should be changed to getDate instead. This is probably not a backward compatibility issue since the new query api is included in 3.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Dynamic objects
Posted by 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
Re: Guidelines for a new datastore adapter
Posted by Andy Jefferson <an...@datanucleus.org>.
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
--
Andy
DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
Guidelines for a new datastore adapter
Posted by Gordan Vosicki <go...@icsa.ch>.
Hi Andy,
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 ?
Best regards,
Gordan Vosicki
ICS Computer Services
Chocolatière 26
CH - 1026 Echandens
http://www.cadics.net