The issue with the SQL-OS is that each data type needs its own custom "valuie mapper" that handles read/writes from/to the database tables.
The native Joda classes would need to be implemented before they can be persisted... Regards, Kevin Jeroen van der Wal <[email protected]> wrote: >First of all there's no intention to break other components by using >Joda >natively. We've added support for Joda in the JDO object store already >and >I recommend that other object stores and viewers will start supporting >Joda >types too, it shouldn't be hard to accomplish that. Marking the applib >date/time classes being deprecated will hint developers to use Joda >over >applib but will not break anything. It's up to the community to do a >vote >on the final removal of the classes but there's no rush to do that. > >Your quick fix to expose the underlying Joda classes would IMHO make >things >more complicated than it should be. One of the drivers to move to Joda >is >that in the current application we're building we have to do a lot of >time >and date based calculations and Joda excels in that. > >A little refactoring should not stop the improvement of the framework >but >perhaps I'm missing some more relevant. > >Kind Regards, > >Jeroen > >On Tue, Sep 18, 2012 at 7:05 PM, Kevin Meyer - KMZ <[email protected]> >wrote: > >> An immediate quick fix would be to provide a getter on the applib >date >> classes that exposes the underlying Joda class... then you could get >> the full access you want, without affecting any other component (e.g. >> the Isis sql object store ;-) ) >> >> Regards, >> Kevin >> >> On 18 Sep 2012 at 16:50, Jeroen van der Wal wrote: >> >> > The reason that I use Joda is because I want to access it full >> capabilities. >> > >> > +1 to mark the applib date/times as deprecated and leave it around >for a >> > while. I'm volunteering to do some refactoring of Isis. >> > >> > Regards, >> > >> > Jeroen >> > >> > >> > >> > >> > On Tue, Sep 18, 2012 at 4:20 PM, Dan Haywood >> > <[email protected]>wrote: >> > >> > > I wonder if we should just get rid of the Isis applib date/times? >> It's not >> > > like our implementation is in any way superior to Joda (rather: >it is >> > > substantially inferior). >> > > >> > > >> > > >> > > On 18 September 2012 14:54, Kevin Meyer - KMZ <[email protected]> >wrote: >> > > >> > > > Hi all, >> > > > >> > > > This probably does not have any direct bearing on this >discussion, >> but >> > > > I have converted all Isis date / time variables to (at their >core) >> use >> > > > Joda time instead of Java time classes... the core Joda time >property >> > > > might not be exposed, though. >> > > > >> > > > Regards, >> > > > Kevin >> > > > >> > > > On 18 Sep 2012 at 15:38, Jeroen van der Wal wrote: >> > > > >> > > > > Hi Minto, >> > > > > >> > > > > 1. UUID is not persisted by default but will be if you mark >it with >> > > > > @Persistent. Don't know from the top of my head if that's >also the >> case >> > > > for >> > > > > the applib.DateTime. As an alternative you can use >> > > org.joda.time.DateTime >> > > > > (which also must be annotated with @Persistent). See the >> Datanucleus >> > > > > documentation on Java types[1] for more information. >> > > > > >> > > > > 2. Collections should be marked with >> > > > > @Persistent(mappedBy="<parent class>") for a 1-N >relationship. Add >> an >> > > > > additional @Join to create a separate join table. Again, >> Datanucleus >> > > > > provides loads of documentation on this topic [2]. >> > > > > >> > > > > Hope this helps. >> > > > > >> > > > > Jeroen >> > > > > >> > > > > [1] >http://www.datanucleus.org/products/datanucleus/jdo/types.html >> > > > > [2] >> > > > > >> > > > >> > > >> >http://www.datanucleus.org/products/datanucleus/jdo/orm/one_to_many_set.html >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Jeroen van der Wal >> > > > > Stromboli b.v. >> > > > > +31 655 874050 >> >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
