isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject [DISCUSSION] Using a DSL as a pure object model (was: Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions)
Date Wed, 11 Sep 2013 07:04:36 GMT
On the "mothballing SQL OS" thread were were discussing the relative merits
or non-merits of an Isis domain model that has lots of JDO annotations
within it.  One possible way forward is to use DataNucleus' metadata API so
that the DN metamodel is mostly built from the Isis metadata.

I'm still slightly uneasy about the
invisibility/opaqueness/difficult-to-debugness of that, but anyway... I
have a slightly different proposition: to offer instead a DSL for writing
Isis domain apps.

In [1] we have a sketch for what such a DSL would look like.  Maurizio and
I have been talking offlist about this, and doing a few little experiments.
 Building this would be comparatively easy.

[Aside: the DSL is called Kemble because Kemble is a village close to
the *source
*of the River Thames/Isis.  Good, huh?].

So, my proposition is as follows:

- for those who want to work in a familiar environment, preserving any
existing skills in JDO (and one day JPA), then keep things as they are.
 This is the "bare metal" view of an Isis domain model.

- for those who want to work at the highest possible abstraction level, let
them work in Kemble.  This would only support Isis annotations and could
use keywords to represent concepts such as bidirectional mapping.  The
generated Java is easily viewable for debugging; this Java would have the
JDO annotations etc etc.

I think that Maurizio (mostly) and I (a little) will be playing with XText
anyway, cos it's a lot of fun.  But it might also be the right way to go
strategically to resolve the debate we've been having.

Thoughts welcome

Dan




[1] https://issues.apache.org/jira/browse/ISIS-369

On 10 September 2013 20:05, Dan Haywood <dan@haywood-associates.co.uk>wrote:

>
>
> On 10 September 2013 19:28, Kevin Meyer - KMZ <kevin@kmz.co.za> wrote:
>
>>
>> I would be interested in knowing if it is possible to use the DN meta
>> data API to allow the JDO data store to make intelligent guesses
>> (that'll generally be "right", or at least a default that is generally
>> useable).
>>
>
> Yes, I think that by and large that would be possible.  Certainly, a lot
> of the Estatio entities are all very similar to each other.
>
> I could also imagine "profiles" whereby we map one way for a "typical"
> RDBMS setup, and a slightly different way to support Google App Engine.
>  (Maurizio tells me off-list that this is working fine; he's in the middle
> of getting his committer perms sorted in order to do the necessary commit).
>
>
>>
>> Then, when the defaults are not good enough (some final deployment
>> tweaking would improve behaviour or performance), let the developer
>> provide JDO annotations as required.
>>
>>
> Yeah, I think that would be necessary.
>
>
>
>> Of course, some Isis annotations (e.g. @Optional) also impact on the
>> database (implicitly requiring "allowNulls = true") and there is possibly
>> no way around this (unless one of the defaults to the datastore is that
>> allowNulls is always true!)
>>
>>
> At the moment we have Isis recognizing @Column(allowsNull=true) to mean
> optional.  But if we use the DN metadata API, then we could go the other
> way (ie use @Optional to setup the DN metamodel instead).
>
>
> So goal is to get the objectstore "working" as soon as possible with no
>> (or very few) data-store specific annotations on the POJOs.
>>
>>
> Very happy to support you on this Kevin.  For myself, I shan't be putting
> any time into it; need to keep focussed on getting Estatio live.
>
>
>
>> So, the question is: Can the metadata API provide enough input to
>> DN that an introspector (using the Isis metamodel) can guess the
>> required DN metadata for entities and properties (single valued and
>> collections) if there are no annotations?
>>
>>
> To a large extent, yes.  The main things we don't have are bidirectional
> relationships and inheritance mapping (roll-up vs table-per-type vs
> roll-down).  For these I think we just recognize the JDO annotations.
>
>
>
>> I don't understand the relationship between JDO and DN, so I would
>> need to do a lot of research first.. ;)
>
>
>
> JDO is the API, DN is the implementation.  (DN also supports the JPA API,
> so after we get this sorted out to our mutual satisfaction, we can go round
> the loop and look at JPA).
>
>
>
>> Perhaps a better understanding
>> would clarify why my goal is pointless (or impossible).
>>
>>
> It's doable.  The question remains: do we expect our would-be users to
> learn the Isis conventions (and learn about its default mappings), or do we
> let them bring their existing JDO (and one day) JPA knowledge and then have
> Isis do "the right thing".
>
>
> Dan
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message