You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by mi...@xup.nl on 2012/09/06 10:44:47 UTC
Object stores JDO vs SQL
Hi folks,
Where can I find additional information regarding the JDO objectstore.
I had to revert from sql back to the in-memory object store when I
switched to isis trunk.
Now I need to have my objects stored in the database again. How best
to move forward?
1) SQL object store is broken in trunk
2) JDO object is not documented
Please advice,
Regards,
Minto
Re: Object stores JDO vs SQL
Posted by Kevin Meyer <ke...@kmz.co.za>.
Hi,
After a long break I hope to have some time to try get the sql-os working again.. but it'll still be some time before I can commit...
Regards,
Kevin
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Object stores JDO vs SQL
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
JDO also supports xml, but I haven't actually tried it out. I suspect it'll
just work. One way or another JDO does need to build its own metamodel.
That's just the way it is ... :-)
Sorry to be brief, sent from my phone
On Sep 6, 2012 1:08 PM, <mi...@xup.nl> wrote:
> Do I really have to place all those JDO annotations in my model ? :(
>
> Regards,
>
> Minto
>
> Quoting Dan Haywood <da...@haywood-associates.co.uk>**:
>
> Yes, it's on the Todo list to provide some docs.
>> The quickstart app is configured for JDO, though, so you could stay there.
>>
>> More detail later today.
>> Dan
>>
>> Sorry to be brief, sent from my phone
>> On Sep 6, 2012 9:45 AM, <mi...@xup.nl> wrote:
>>
>> Hi folks,
>>>
>>> Where can I find additional information regarding the JDO objectstore. I
>>> had to revert from sql back to the in-memory object store when I switched
>>> to isis trunk.
>>>
>>> Now I need to have my objects stored in the database again. How best to
>>> move forward?
>>>
>>> 1) SQL object store is broken in trunk
>>> 2) JDO object is not documented
>>>
>>> Please advice,
>>>
>>> Regards,
>>>
>>> Minto
>>>
>>>
>>
>
>
Re: Runtime model
Posted by Matthew Adams <ma...@matthewadams.me>.
FYI, for models defined at runtime, you can use the metadata & enhancer
APIs now in the latest version of DataNucleus:
http://www.datanucleus.org/products/datanucleus/jdo/metadata_api.html
http://www.datanucleus.org/products/datanucleus/enhancer.html#api
HTH,
Matthew
On Sun, Sep 9, 2012 at 9:01 AM, Minto van der Sluis <mi...@xup.nl> wrote:
> Thanks for al the responses regarding JDO vs SQL.
>
> However, my project moved in a direction where the model is not known at
> compile time. So we need a solution capable of handling the model at
> runtime. I am not sure if there still is a place for Isis in this scenario.
>
> Currently I am thinking about modelling the domain in OWL and store the
> data in a RDF database. Metawidget comes to mind for constructing a Gui
> at runtime.
>
> Regards,
>
> Minto
>
>
> Op 6-9-2012 20:58, Matthew Adams schreef:
> > If you didn't like the JDO annotations in your source, you have one other
> > option I can think of besides the xml metadata option.
> >
> > NB: I think it's a pretty heavyweight solution for just a metadata
> > location preference.
> >
> > You could also use AspectJ to introduce the annotations orthogonally.
> They
> > would be there at runtime, but you wouldn't see them in source. It would
> > take some changes to your build environment (I recommend just replacing
> > javac with ajc), but you need to make sure that if you use AspectJ, do it
> > before enhancing.
> >
> > Note that today, I'd say the best practice in JDO is to use annotations
> for
> > logical metadata (like @PersistenceCapable -- those things that don't
> > change as a function of your datastore type or vendor) and XML metadata
> for
> > physical metadata (like OR mappings or other metadata that does change
> as a
> > function of your datastore type & vendor). It's a fact of life that
> > writing persistent objects is different than writing transient ones...
> >
> > Perhaps the Isis team could provide aspects or similar functionality that
> > introduce the appropriate JDO metadata (annotations and/or XML) based on
> > its own metadata.
> >
> > -matthew
> >
> > On Thu, Sep 6, 2012 at 12:31 PM, Dan Haywood
> > <da...@haywood-associates.co.uk>wrote:
> >
> >> Jeroen and I talked were also talking about this (he and I are using the
> >> JDO object store in anger on a project we're working on together). I do
> >> suspect that it would be possible to "teach" DataNucleus (the underlying
> >> JDO implementation) about some of Isis' annotations and conventions,
> thus
> >> reducing the amount of stuff.
> >>
> >> However, we both decided that would be a bad idea. After all, the JDO
> >> community is that much larger (Google app engine, for example) and more
> >> established than our own. And hopefully some of those users will come
> >> across Isis and see its support for JDO, and think about trying it out.
> It
> >> wouldn't be a good experience if they have to unlearn hard-learnt JDO
> >> annotations/conventions and try to figure out how Isis interacts with
> JDO.
> >>
> >> On the other hand, if there are semantics that we can infer into Isis
> from
> >> JDO annotations, then that direction is just fine. For example,
> >> @javax.jdo.Embedded annotation is basically the same as the Isis
> >> @Aggregated annotation, and so we infer the AggregatedFact from it.
> >>
> >> Dan
> >>
> >> On 6 September 2012 18:18, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> >>
> >>> Now you know why I like the sql-os so much! No annotations, just a
> >>> few occaisional overrides in the properties file..
> >>>
> >>> I'm slowly reconstrucing my build enviroment (I have recently moved
> >>> into temporary accommodation).. should able to make some progress
> >>> soon.
> >>>
> >>> Regards,
> >>> Kevin
> >>>
> >>> On 6 Sep 2012 at 14:07, minto@xup.nl wrote:
> >>>
> >>>> Do I really have to place all those JDO annotations in my model ? :(
> >>>>
> >>>> Regards,
> >>>>
> >>>> Minto
> >>>>
> >>>> Quoting Dan Haywood <da...@haywood-associates.co.uk>:
> >>>>
> >>>>> Yes, it's on the Todo list to provide some docs.
> >>>>> The quickstart app is configured for JDO, though, so you could stay
> >>> there.
> >>>>>
> >>>>> More detail later today.
> >>>>> Dan
> >>>>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
> --
> ir. ing. Minto van der Sluis
> Software innovator / renovator
> Xup BV
>
> Mobiel: +31 (0) 626 014541
>
--
mailto:matthew@matthewadams.me <ma...@matthewadams.me>
skype:matthewadams12
googletalk:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
Re: Runtime model
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Right you are. Good luck.
Dan
On 10 September 2012 20:32, Minto van der Sluis <mi...@xup.nl> wrote:
> Hi Dan,
>
> Thanks a lot for thinking along out loud.
>
> Actually I found another Apache project called Stanbol (
> http://incubator.apache.org/stanbol ) that does a few thing we need. I
> will further investigate that and keep your words in mind.
>
> Regards,
>
> Minto
>
> Op 10-9-2012 9:06, Dan Haywood schreef:
> > On 9 September 2012 15:01, Minto van der Sluis <mi...@xup.nl> wrote:
> >
> >> Thanks for al the responses regarding JDO vs SQL.
> >>
> >> However, my project moved in a direction where the model is not known at
> >> compile time. So we need a solution capable of handling the model at
> >> runtime. I am not sure if there still is a place for Isis in this
> scenario.
> >>
> >
> > That definitely rules out using one of the current objectstores, and
> indeed
> > most of Isis' runtime infrastructure.
> >
> > With a little inside knowledge, I think it would be possible to use the
> > core (metamodel) and the viewers, however. You would need to implement a
> > number of FacetFactory's in order to build the metamodel from, well,
> > wherever the information is. And you'd need to provide the backend
> runtime
> > also, wrapped up in a form that Isis can access (ie through the
> IsisContext
> > service locator).
> >
> >
> >
> >>
> >> Currently I am thinking about modelling the domain in OWL and store the
> >> data in a RDF database. Metawidget comes to mind for constructing a Gui
> >> at runtime.
> >>
> >
> > That may well be a good approach. You'll find that to use Metawidget
> > you'll also need to implement its MetaModelBuilder API, and of course
> with
> > MetaWidget you do all the backend runtime/persistence yourself anyway.
> >
> > My suggestion would be that you figure out your runtime/backend, using a
> > very simple UI (to the console, even). Once you understand that, then
> > you'll be in a better position to decide which framework (if either) to
> go
> > with.
> >
> > Cheers
> > Dan
> >
> >
> >
> >>
> >> Regards,
> >>
> >> Minto
> >>
> >>
> >
>
>
> --
> ir. ing. Minto van der Sluis
> Software innovator / renovator
> Xup BV
>
> Mobiel: +31 (0) 626 014541
>
Re: Runtime model
Posted by Minto van der Sluis <mi...@xup.nl>.
Hi Dan,
Thanks a lot for thinking along out loud.
Actually I found another Apache project called Stanbol (
http://incubator.apache.org/stanbol ) that does a few thing we need. I
will further investigate that and keep your words in mind.
Regards,
Minto
Op 10-9-2012 9:06, Dan Haywood schreef:
> On 9 September 2012 15:01, Minto van der Sluis <mi...@xup.nl> wrote:
>
>> Thanks for al the responses regarding JDO vs SQL.
>>
>> However, my project moved in a direction where the model is not known at
>> compile time. So we need a solution capable of handling the model at
>> runtime. I am not sure if there still is a place for Isis in this scenario.
>>
>
> That definitely rules out using one of the current objectstores, and indeed
> most of Isis' runtime infrastructure.
>
> With a little inside knowledge, I think it would be possible to use the
> core (metamodel) and the viewers, however. You would need to implement a
> number of FacetFactory's in order to build the metamodel from, well,
> wherever the information is. And you'd need to provide the backend runtime
> also, wrapped up in a form that Isis can access (ie through the IsisContext
> service locator).
>
>
>
>>
>> Currently I am thinking about modelling the domain in OWL and store the
>> data in a RDF database. Metawidget comes to mind for constructing a Gui
>> at runtime.
>>
>
> That may well be a good approach. You'll find that to use Metawidget
> you'll also need to implement its MetaModelBuilder API, and of course with
> MetaWidget you do all the backend runtime/persistence yourself anyway.
>
> My suggestion would be that you figure out your runtime/backend, using a
> very simple UI (to the console, even). Once you understand that, then
> you'll be in a better position to decide which framework (if either) to go
> with.
>
> Cheers
> Dan
>
>
>
>>
>> Regards,
>>
>> Minto
>>
>>
>
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
Re: Runtime model
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 9 September 2012 15:01, Minto van der Sluis <mi...@xup.nl> wrote:
> Thanks for al the responses regarding JDO vs SQL.
>
> However, my project moved in a direction where the model is not known at
> compile time. So we need a solution capable of handling the model at
> runtime. I am not sure if there still is a place for Isis in this scenario.
>
That definitely rules out using one of the current objectstores, and indeed
most of Isis' runtime infrastructure.
With a little inside knowledge, I think it would be possible to use the
core (metamodel) and the viewers, however. You would need to implement a
number of FacetFactory's in order to build the metamodel from, well,
wherever the information is. And you'd need to provide the backend runtime
also, wrapped up in a form that Isis can access (ie through the IsisContext
service locator).
>
> Currently I am thinking about modelling the domain in OWL and store the
> data in a RDF database. Metawidget comes to mind for constructing a Gui
> at runtime.
>
That may well be a good approach. You'll find that to use Metawidget
you'll also need to implement its MetaModelBuilder API, and of course with
MetaWidget you do all the backend runtime/persistence yourself anyway.
My suggestion would be that you figure out your runtime/backend, using a
very simple UI (to the console, even). Once you understand that, then
you'll be in a better position to decide which framework (if either) to go
with.
Cheers
Dan
>
> Regards,
>
> Minto
>
>
Runtime model
Posted by Minto van der Sluis <mi...@xup.nl>.
Thanks for al the responses regarding JDO vs SQL.
However, my project moved in a direction where the model is not known at
compile time. So we need a solution capable of handling the model at
runtime. I am not sure if there still is a place for Isis in this scenario.
Currently I am thinking about modelling the domain in OWL and store the
data in a RDF database. Metawidget comes to mind for constructing a Gui
at runtime.
Regards,
Minto
Op 6-9-2012 20:58, Matthew Adams schreef:
> If you didn't like the JDO annotations in your source, you have one other
> option I can think of besides the xml metadata option.
>
> NB: I think it's a pretty heavyweight solution for just a metadata
> location preference.
>
> You could also use AspectJ to introduce the annotations orthogonally. They
> would be there at runtime, but you wouldn't see them in source. It would
> take some changes to your build environment (I recommend just replacing
> javac with ajc), but you need to make sure that if you use AspectJ, do it
> before enhancing.
>
> Note that today, I'd say the best practice in JDO is to use annotations for
> logical metadata (like @PersistenceCapable -- those things that don't
> change as a function of your datastore type or vendor) and XML metadata for
> physical metadata (like OR mappings or other metadata that does change as a
> function of your datastore type & vendor). It's a fact of life that
> writing persistent objects is different than writing transient ones...
>
> Perhaps the Isis team could provide aspects or similar functionality that
> introduce the appropriate JDO metadata (annotations and/or XML) based on
> its own metadata.
>
> -matthew
>
> On Thu, Sep 6, 2012 at 12:31 PM, Dan Haywood
> <da...@haywood-associates.co.uk>wrote:
>
>> Jeroen and I talked were also talking about this (he and I are using the
>> JDO object store in anger on a project we're working on together). I do
>> suspect that it would be possible to "teach" DataNucleus (the underlying
>> JDO implementation) about some of Isis' annotations and conventions, thus
>> reducing the amount of stuff.
>>
>> However, we both decided that would be a bad idea. After all, the JDO
>> community is that much larger (Google app engine, for example) and more
>> established than our own. And hopefully some of those users will come
>> across Isis and see its support for JDO, and think about trying it out. It
>> wouldn't be a good experience if they have to unlearn hard-learnt JDO
>> annotations/conventions and try to figure out how Isis interacts with JDO.
>>
>> On the other hand, if there are semantics that we can infer into Isis from
>> JDO annotations, then that direction is just fine. For example,
>> @javax.jdo.Embedded annotation is basically the same as the Isis
>> @Aggregated annotation, and so we infer the AggregatedFact from it.
>>
>> Dan
>>
>> On 6 September 2012 18:18, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>>
>>> Now you know why I like the sql-os so much! No annotations, just a
>>> few occaisional overrides in the properties file..
>>>
>>> I'm slowly reconstrucing my build enviroment (I have recently moved
>>> into temporary accommodation).. should able to make some progress
>>> soon.
>>>
>>> Regards,
>>> Kevin
>>>
>>> On 6 Sep 2012 at 14:07, minto@xup.nl wrote:
>>>
>>>> Do I really have to place all those JDO annotations in my model ? :(
>>>>
>>>> Regards,
>>>>
>>>> Minto
>>>>
>>>> Quoting Dan Haywood <da...@haywood-associates.co.uk>:
>>>>
>>>>> Yes, it's on the Todo list to provide some docs.
>>>>> The quickstart app is configured for JDO, though, so you could stay
>>> there.
>>>>>
>>>>> More detail later today.
>>>>> Dan
>>>>>
>>>
>>>
>>
>
>
>
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
Re: Object stores JDO vs SQL
Posted by Matthew Adams <ma...@matthewadams.me>.
If you didn't like the JDO annotations in your source, you have one other
option I can think of besides the xml metadata option.
NB: I think it's a pretty heavyweight solution for just a metadata
location preference.
You could also use AspectJ to introduce the annotations orthogonally. They
would be there at runtime, but you wouldn't see them in source. It would
take some changes to your build environment (I recommend just replacing
javac with ajc), but you need to make sure that if you use AspectJ, do it
before enhancing.
Note that today, I'd say the best practice in JDO is to use annotations for
logical metadata (like @PersistenceCapable -- those things that don't
change as a function of your datastore type or vendor) and XML metadata for
physical metadata (like OR mappings or other metadata that does change as a
function of your datastore type & vendor). It's a fact of life that
writing persistent objects is different than writing transient ones...
Perhaps the Isis team could provide aspects or similar functionality that
introduce the appropriate JDO metadata (annotations and/or XML) based on
its own metadata.
-matthew
On Thu, Sep 6, 2012 at 12:31 PM, Dan Haywood
<da...@haywood-associates.co.uk>wrote:
> Jeroen and I talked were also talking about this (he and I are using the
> JDO object store in anger on a project we're working on together). I do
> suspect that it would be possible to "teach" DataNucleus (the underlying
> JDO implementation) about some of Isis' annotations and conventions, thus
> reducing the amount of stuff.
>
> However, we both decided that would be a bad idea. After all, the JDO
> community is that much larger (Google app engine, for example) and more
> established than our own. And hopefully some of those users will come
> across Isis and see its support for JDO, and think about trying it out. It
> wouldn't be a good experience if they have to unlearn hard-learnt JDO
> annotations/conventions and try to figure out how Isis interacts with JDO.
>
> On the other hand, if there are semantics that we can infer into Isis from
> JDO annotations, then that direction is just fine. For example,
> @javax.jdo.Embedded annotation is basically the same as the Isis
> @Aggregated annotation, and so we infer the AggregatedFact from it.
>
> Dan
>
> On 6 September 2012 18:18, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
> > Now you know why I like the sql-os so much! No annotations, just a
> > few occaisional overrides in the properties file..
> >
> > I'm slowly reconstrucing my build enviroment (I have recently moved
> > into temporary accommodation).. should able to make some progress
> > soon.
> >
> > Regards,
> > Kevin
> >
> > On 6 Sep 2012 at 14:07, minto@xup.nl wrote:
> >
> > > Do I really have to place all those JDO annotations in my model ? :(
> > >
> > > Regards,
> > >
> > > Minto
> > >
> > > Quoting Dan Haywood <da...@haywood-associates.co.uk>:
> > >
> > > > Yes, it's on the Todo list to provide some docs.
> > > > The quickstart app is configured for JDO, though, so you could stay
> > there.
> > > >
> > > > More detail later today.
> > > > Dan
> > > >
> >
> >
>
--
mailto:matthew@matthewadams.me <ma...@matthewadams.me>
skype:matthewadams12
googletalk:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
Re: Object stores JDO vs SQL
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Jeroen and I talked were also talking about this (he and I are using the
JDO object store in anger on a project we're working on together). I do
suspect that it would be possible to "teach" DataNucleus (the underlying
JDO implementation) about some of Isis' annotations and conventions, thus
reducing the amount of stuff.
However, we both decided that would be a bad idea. After all, the JDO
community is that much larger (Google app engine, for example) and more
established than our own. And hopefully some of those users will come
across Isis and see its support for JDO, and think about trying it out. It
wouldn't be a good experience if they have to unlearn hard-learnt JDO
annotations/conventions and try to figure out how Isis interacts with JDO.
On the other hand, if there are semantics that we can infer into Isis from
JDO annotations, then that direction is just fine. For example,
@javax.jdo.Embedded annotation is basically the same as the Isis
@Aggregated annotation, and so we infer the AggregatedFact from it.
Dan
On 6 September 2012 18:18, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> Now you know why I like the sql-os so much! No annotations, just a
> few occaisional overrides in the properties file..
>
> I'm slowly reconstrucing my build enviroment (I have recently moved
> into temporary accommodation).. should able to make some progress
> soon.
>
> Regards,
> Kevin
>
> On 6 Sep 2012 at 14:07, minto@xup.nl wrote:
>
> > Do I really have to place all those JDO annotations in my model ? :(
> >
> > Regards,
> >
> > Minto
> >
> > Quoting Dan Haywood <da...@haywood-associates.co.uk>:
> >
> > > Yes, it's on the Todo list to provide some docs.
> > > The quickstart app is configured for JDO, though, so you could stay
> there.
> > >
> > > More detail later today.
> > > Dan
> > >
>
>
Re: Object stores JDO vs SQL
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
Now you know why I like the sql-os so much! No annotations, just a
few occaisional overrides in the properties file..
I'm slowly reconstrucing my build enviroment (I have recently moved
into temporary accommodation).. should able to make some progress
soon.
Regards,
Kevin
On 6 Sep 2012 at 14:07, minto@xup.nl wrote:
> Do I really have to place all those JDO annotations in my model ? :(
>
> Regards,
>
> Minto
>
> Quoting Dan Haywood <da...@haywood-associates.co.uk>:
>
> > Yes, it's on the Todo list to provide some docs.
> > The quickstart app is configured for JDO, though, so you could stay there.
> >
> > More detail later today.
> > Dan
> >
Re: Object stores JDO vs SQL
Posted by mi...@xup.nl.
Do I really have to place all those JDO annotations in my model ? :(
Regards,
Minto
Quoting Dan Haywood <da...@haywood-associates.co.uk>:
> Yes, it's on the Todo list to provide some docs.
> The quickstart app is configured for JDO, though, so you could stay there.
>
> More detail later today.
> Dan
>
> Sorry to be brief, sent from my phone
> On Sep 6, 2012 9:45 AM, <mi...@xup.nl> wrote:
>
>> Hi folks,
>>
>> Where can I find additional information regarding the JDO objectstore. I
>> had to revert from sql back to the in-memory object store when I switched
>> to isis trunk.
>>
>> Now I need to have my objects stored in the database again. How best to
>> move forward?
>>
>> 1) SQL object store is broken in trunk
>> 2) JDO object is not documented
>>
>> Please advice,
>>
>> Regards,
>>
>> Minto
>>
>
Re: Object stores JDO vs SQL
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Yes, it's on the Todo list to provide some docs.
The quickstart app is configured for JDO, though, so you could stay there.
More detail later today.
Dan
Sorry to be brief, sent from my phone
On Sep 6, 2012 9:45 AM, <mi...@xup.nl> wrote:
> Hi folks,
>
> Where can I find additional information regarding the JDO objectstore. I
> had to revert from sql back to the in-memory object store when I switched
> to isis trunk.
>
> Now I need to have my objects stored in the database again. How best to
> move forward?
>
> 1) SQL object store is broken in trunk
> 2) JDO object is not documented
>
> Please advice,
>
> Regards,
>
> Minto
>