You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2012/09/18 16:20:54 UTC
Re: Stuck on using JDO object store.
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 <ke...@kmz.co.za> 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
> >
> >
> > On Tue, Sep 18, 2012 at 2:35 PM, <mi...@xup.nl> wrote:
> >
> > > Hi folks,
> > >
> > > I am sort of stuck when using the JDO object store. I basically have 2
> > > issues that I need to resolve.
> > >
> > > Issue 1: UUID and DateTime are not stored
> > > ------------------------------**------------
> > > When creating a new Report (without any statuses) the timestamp and
> uuid
> > > are automatically generated. So on initial create there are no edit
> fields
> > > for these 2 properties as expected. Pressing 'Ok' stores the
> information in
> > > the database and shows the details view where both fields are shown
> with
> > > proper data.
> > > However when retrieving the same record from the database both these
> > > fields are shown empty.
> > >
> > > What could have caused this behaviour (where do I have to look)?
> > > Do I have to do something special to get these values to be stored as
> well?
> > >
> > > Issue 2: Statusses are not attached to report
> > > ------------------------------**---------------
> > > I have troubles adding a status to the report. When looking in the
> > > database I find tables for both Report and Status. But I can not find
> any
> > > relation between both tables.
> > >
> > > I am probably overlooking something but I can't figure out what?
> > >
> > > Model:
> > > ------
> > > class Report {
> > > UUID uuid;
> > > DateTime timestamp // Isis DateTime
> > > String reporter;
> > > String reason;
> > > List<Status> statuses;
> > > }
> > >
> > > class Status {
> > > DateTime timestamp // Isis DateTime
> > > String remark;
> > > Integer statusValue;
> > > }
> > >
> > > - For UUID I created a ValueSemanticsProvider. The value is shown
> properly
> > > on screen.
> > > - The ReportRepository contains methods for creating a new Report and
> > > searching for reports.
> > > - Statuses are created through Report.addStatus() looking something
> like
> > > this:
> > >
> > > public void addStatus( @Named("Partij") Integer partij,
> > > @Named("Duider") String duider,
> > > @Named("Status") Integer status,
> > > @Named("Toelichting") String toelichting) {
> > > final Status statusObject = newTransientInstance(Status.**class);
> > > statusObject.set...
> > > statuses.add(statusObject); // Shouldn't 'this' be saved as well?
> > > persist(statusObject);
> > > }
> > >
> > >
> > > Environment:
> > > ------------
> > > 0.3.1-SNAPSHOT
> > > JDO objectstore on postgresql
> > > Html viewer
> > >
> > > Any help is greatly appreciated.
> > >
> > > Regards,
> > >
> > > Minto
>
>
Re: Stuck on using JDO object store.
Posted by Kevin Meyer <ke...@kmz.co.za>.
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 <je...@stromboli.it> 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 <ke...@kmz.co.za>
>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
>> > <da...@haywood-associates.co.uk>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 <ke...@kmz.co.za>
>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.
Re: Stuck on using JDO object store.
Posted by Jeroen van der Wal <je...@stromboli.it>.
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 <ke...@kmz.co.za> 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
> > <da...@haywood-associates.co.uk>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 <ke...@kmz.co.za> 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
>
>
Re: Stuck on using JDO object store.
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
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
> <da...@haywood-associates.co.uk>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 <ke...@kmz.co.za> 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
Re: Stuck on using JDO object store.
Posted by Jeroen van der Wal <je...@stromboli.it>.
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
<da...@haywood-associates.co.uk>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 <ke...@kmz.co.za> 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
> > >
> > >
> > > On Tue, Sep 18, 2012 at 2:35 PM, <mi...@xup.nl> wrote:
> > >
> > > > Hi folks,
> > > >
> > > > I am sort of stuck when using the JDO object store. I basically have
> 2
> > > > issues that I need to resolve.
> > > >
> > > > Issue 1: UUID and DateTime are not stored
> > > > ------------------------------**------------
> > > > When creating a new Report (without any statuses) the timestamp and
> > uuid
> > > > are automatically generated. So on initial create there are no edit
> > fields
> > > > for these 2 properties as expected. Pressing 'Ok' stores the
> > information in
> > > > the database and shows the details view where both fields are shown
> > with
> > > > proper data.
> > > > However when retrieving the same record from the database both these
> > > > fields are shown empty.
> > > >
> > > > What could have caused this behaviour (where do I have to look)?
> > > > Do I have to do something special to get these values to be stored as
> > well?
> > > >
> > > > Issue 2: Statusses are not attached to report
> > > > ------------------------------**---------------
> > > > I have troubles adding a status to the report. When looking in the
> > > > database I find tables for both Report and Status. But I can not find
> > any
> > > > relation between both tables.
> > > >
> > > > I am probably overlooking something but I can't figure out what?
> > > >
> > > > Model:
> > > > ------
> > > > class Report {
> > > > UUID uuid;
> > > > DateTime timestamp // Isis DateTime
> > > > String reporter;
> > > > String reason;
> > > > List<Status> statuses;
> > > > }
> > > >
> > > > class Status {
> > > > DateTime timestamp // Isis DateTime
> > > > String remark;
> > > > Integer statusValue;
> > > > }
> > > >
> > > > - For UUID I created a ValueSemanticsProvider. The value is shown
> > properly
> > > > on screen.
> > > > - The ReportRepository contains methods for creating a new Report and
> > > > searching for reports.
> > > > - Statuses are created through Report.addStatus() looking something
> > like
> > > > this:
> > > >
> > > > public void addStatus( @Named("Partij") Integer partij,
> > > > @Named("Duider") String duider,
> > > > @Named("Status") Integer status,
> > > > @Named("Toelichting") String toelichting) {
> > > > final Status statusObject = newTransientInstance(Status.**class);
> > > > statusObject.set...
> > > > statuses.add(statusObject); // Shouldn't 'this' be saved as
> well?
> > > > persist(statusObject);
> > > > }
> > > >
> > > >
> > > > Environment:
> > > > ------------
> > > > 0.3.1-SNAPSHOT
> > > > JDO objectstore on postgresql
> > > > Html viewer
> > > >
> > > > Any help is greatly appreciated.
> > > >
> > > > Regards,
> > > >
> > > > Minto
> >
> >
>