The JDO stuff is really nice and a big move forward for Isis, thanks for
all the good work you did on that. I also like Kevin's objective so I was
wondering if a JDO implemention with none or a single annotation would be
possible? I can imagine that a "Convention over Configuration" approach
helps in moving everybody over to JDO.
For example: currently, working with JDO, I find myself adding these
annotations to almost each entity:
@PersistenceCapable(schema = "asset", identityType =
IdentityType.DATASTORE)
@DatastoreIdentity(strategy = IdGeneratorStrategy.IDENTITY)
@Inheritance(strategy = InheritanceStrategy.NEW_TABLE)
@ObjectType("PROP")
where in fact I only want to add this:
@PersistenceCapable
Perhaps we can work out the best convention together and set that as the
Isis default?
Cheers,
Jeroen
On Thu, Aug 30, 2012 at 11:58 AM, Dan Haywood
<[email protected]>wrote:
> All,
>
> As you might have noticed, I've been tapped away implementing [ISIS-14],
> namely adding a JDO object store implemented using DataNucleus (DN is
> Apache 2.0 licensed, and is the reference implementation for the JDO spec).
>
> At the same time, I've been doing other work to simplify down the runtime
> components within Isis. One of these was the removal of the remoting
> support (ISIS-131), another was making Oids immutable and self-describing
> (ISIS-216), another was collapsing the Version hierarchy (ISIS-245),
> another was storing version information inside Oids to simplify concurrency
> checking (ISIS-248).
>
> Most of these changes shouldn't impact existing objectstores/viewers etc
> (and open up the possibility of simpifying them in the future); however
> ISIS-216 in particular was a big change. Rob Matthews has been ensuring
> that the in-memory object store, the NoSql and the XML object stores work
> with the changes introduced here. However, Kevin Meyer, the primary
> maintainer of the SQL object store, has not been able to be as involved in
> the project as much as previously, and so no additional testing has been
> performed on SQL os with respect to these changes.
>
> For myself, I'm uncomfortable releasing the SQL object store without some
> additional testing. That said, I'm unenthusiastic to do it myself because
> my intention is to use the JDO object store going forward.
>
> I know that the SQL object store and JDO object store don't overlap exactly
> in their use cases; one of Kevin's objectives for the SQL os was to have
> annotation-free domain models, which most certainly is *not* the case with
> a JDO object store. On the other hand, DataNucleus has many more features
> than our own SQL os; my suspicion is that newcomers would probably prefer
> to use an established ORM rather than a home-grown one.
>
> Therefore, my proposal is that we retire (perhaps temporarily, perhaps for
> good) the SQL object store as of 0.3.1-incubating.
>
> Thoughts, votes, opinions, please!
>
> Thx
> Dan
>
>
> [ISIS-14] https://issues.apache.org/jira/browse/ISIS-14
> [ISIS-131] https://issues.apache.org/jira/browse/ISIS-131
> [ISIS-216] https://issues.apache.org/jira/browse/ISIS-216
> [ISIS-245] https://issues.apache.org/jira/browse/ISIS-245
> [ISIS-248] https://issues.apache.org/jira/browse/ISIS-248
>
