final Oid refactoring changes committed

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi all (in particular, Rob and Kevin)...

as you might have seen, I did a chunk more commits on the Oid refactoring.
 I had a green build locally, but the overnight build was a little
inconclusive, because I had forgotten to commit a file or two.  As I write,
I've queued a further build up, so we'll see how it goes.

As per the previous email, this refactoring has impacted a lot of
components, and it is inevitable that some things are going to be broken...
some intentionally, some unintentionally.

Kevin/Rob...
when refactoring, I decided to comment out defunct code and put in its
replacement.  Thus, if you are reviewing a change and think I've made a
mistake (definitely possible), then hopefully it'll be that much easier to
detect.  What I'll do is to start deleting this commented out code now
going forward; I just wanted there to be a commit where it was relatively
easy to see before and after changes.

Kevin/Rob...
the other thing to be aware of is that I have intentionally broken the
serialization format for XML, SQL and NoSQL OS.  For example, the NoSQL
would serialize a "_type" and an "_id" property.  Nominally, now serializes
an "_oid" instead of both.  (In fact, it does still serialize the "_id",
but this is because Mongo requires such an id).

My rationale for doing this is that I wanted to get down to the simplest
possible code if I could.  If you (or anyone else, of course), have
deployed systems where there's a requirement to read "legacy" serialization
formats, then we can add back in some code just to address this requirement
(a decorator, perhaps?).  I would hope that this isn't a major piece of
work to do.

Rob...
Going back to last nights build, the NoSQL build failed because Mongo
server wasn't running on the build box... I don't ever recall us requesting
that to be set up for us, so am a bit confused as to how this used to be
green. Any ideas?

~~~
I'm sure there'll be some fall-out from this, but in general I'm happy
about how much simpler quite a lot of the code is.  In particular, I can
see that it ought to be quite easy to make the HTML viewer stateless .. the
PersistentRootAdapterMapping is probably not required, and we could also
probably serialize the TransientRootAdapterMapping info into a URL encoded
JSON stream and embed within the page.

~~~
Next steps... I hope to have some further time this week to work on Isis.
 What I want to do next is to build up the "TCK" application so that we can
get a canonical test app from which we can build some object store contract
tests.  Right now the various object stores are tested to differing levels
of completeness; having a TCK will make ensure a consistent level of
quality for the current object stores, and set a target for any new object
stores (eg the JPA object store I intend to revive, and the Cayenne object
store that Kevin has in his back pocket some where).

That's all for now.
Dan

Re: final Oid refactoring changes committed

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Kevin,

Sure, I don't have any problem with bumping direct from 0.3.0-SNAPSHOT to
0.3.1-SNAPSHOT, if that helps.  For anyone else: speak now if you have a
problem with that!

The SQL OS tests do all pass (though I haven't checked the "served" ones).
 As I say I intend to write some more thorough tests for all objectstores
... the idea being to create a superset of all those currently written.
The SQL OS tests are among the more thorough, as I recall.

Dan
~~~~~~~

On 15 May 2012 15:02, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:

> Hi Dan,
>
> As you can imagine, I am a little strapped for time right now.
>
> But I can tell you that I do have one deployed application out there,
> that is currently being used (possibly on a daily basis) ;-)
>
> For the moment, I will assume that if I have to do any framework
> changes, I have to use a snapshot of the framework before you
> started...
>
> I wonder if you can do a minor version bump, so that I can do a build
> and not replace my current binaries in my maven repository?
>
>
>
> I will need to do some rigorous testing before deploying your current
> changes...
>
> But! Despite this, I trust you had good reasons for embarking on this
> change, so, Well Done!
>
> I assume my sql-os tests all pass? (at least the non-server ones, as
> you will need to configure your own mysql and postgresql servers for
> them).
>
> When I find some more time again, maybe your changes will make the
> Cayenne-based OS easier to complete.
>
> Regards,
> Kevin
>
>
>
> On 15 May 2012 at 7:45, Dan Haywood wrote:
>
> > Hi all (in particular, Rob and Kevin)...
> >
> > as you might have seen, I did a chunk more commits on the Oid
> refactoring.
> >  I had a green build locally, but the overnight build was a little
> > inconclusive, because I had forgotten to commit a file or two.  As I
> write,
> > I've queued a further build up, so we'll see how it goes.
> >
> > As per the previous email, this refactoring has impacted a lot of
> > components, and it is inevitable that some things are going to be
> broken...
> > some intentionally, some unintentionally.
> >
> > Kevin/Rob...
> > when refactoring, I decided to comment out defunct code and put in its
> > replacement.  Thus, if you are reviewing a change and think I've made a
> > mistake (definitely possible), then hopefully it'll be that much easier
> to
> > detect.  What I'll do is to start deleting this commented out code now
> > going forward; I just wanted there to be a commit where it was relatively
> > easy to see before and after changes.
> >
> > Kevin/Rob...
> > the other thing to be aware of is that I have intentionally broken the
> > serialization format for XML, SQL and NoSQL OS.  For example, the NoSQL
> > would serialize a "_type" and an "_id" property.  Nominally, now
> serializes
> > an "_oid" instead of both.  (In fact, it does still serialize the "_id",
> > but this is because Mongo requires such an id).
> >
> > My rationale for doing this is that I wanted to get down to the simplest
> > possible code if I could.  If you (or anyone else, of course), have
> > deployed systems where there's a requirement to read "legacy"
> serialization
> > formats, then we can add back in some code just to address this
> requirement
> > (a decorator, perhaps?).  I would hope that this isn't a major piece of
> > work to do.
> >
> > Rob...
> > Going back to last nights build, the NoSQL build failed because Mongo
> > server wasn't running on the build box... I don't ever recall us
> requesting
> > that to be set up for us, so am a bit confused as to how this used to be
> > green. Any ideas?
> >
> > ~~~
> > I'm sure there'll be some fall-out from this, but in general I'm happy
> > about how much simpler quite a lot of the code is.  In particular, I can
> > see that it ought to be quite easy to make the HTML viewer stateless ..
> the
> > PersistentRootAdapterMapping is probably not required, and we could also
> > probably serialize the TransientRootAdapterMapping info into a URL
> encoded
> > JSON stream and embed within the page.
> >
> > ~~~
> > Next steps... I hope to have some further time this week to work on Isis.
> >  What I want to do next is to build up the "TCK" application so that we
> can
> > get a canonical test app from which we can build some object store
> contract
> > tests.  Right now the various object stores are tested to differing
> levels
> > of completeness; having a TCK will make ensure a consistent level of
> > quality for the current object stores, and set a target for any new
> object
> > stores (eg the JPA object store I intend to revive, and the Cayenne
> object
> > store that Kevin has in his back pocket some where).
> >
> > That's all for now.
> > Dan
>
>

Re: final Oid refactoring changes committed

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

Hi Dan,

As you can imagine, I am a little strapped for time right now.

But I can tell you that I do have one deployed application out there, 
that is currently being used (possibly on a daily basis) ;-)

For the moment, I will assume that if I have to do any framework 
changes, I have to use a snapshot of the framework before you 
started...

I wonder if you can do a minor version bump, so that I can do a build 
and not replace my current binaries in my maven repository?



I will need to do some rigorous testing before deploying your current 
changes...

But! Despite this, I trust you had good reasons for embarking on this 
change, so, Well Done!

I assume my sql-os tests all pass? (at least the non-server ones, as 
you will need to configure your own mysql and postgresql servers for 
them).

When I find some more time again, maybe your changes will make the 
Cayenne-based OS easier to complete.

Regards,
Kevin



On 15 May 2012 at 7:45, Dan Haywood wrote:

> Hi all (in particular, Rob and Kevin)...
> 
> as you might have seen, I did a chunk more commits on the Oid refactoring.
>  I had a green build locally, but the overnight build was a little
> inconclusive, because I had forgotten to commit a file or two.  As I write,
> I've queued a further build up, so we'll see how it goes.
> 
> As per the previous email, this refactoring has impacted a lot of
> components, and it is inevitable that some things are going to be broken...
> some intentionally, some unintentionally.
> 
> Kevin/Rob...
> when refactoring, I decided to comment out defunct code and put in its
> replacement.  Thus, if you are reviewing a change and think I've made a
> mistake (definitely possible), then hopefully it'll be that much easier to
> detect.  What I'll do is to start deleting this commented out code now
> going forward; I just wanted there to be a commit where it was relatively
> easy to see before and after changes.
> 
> Kevin/Rob...
> the other thing to be aware of is that I have intentionally broken the
> serialization format for XML, SQL and NoSQL OS.  For example, the NoSQL
> would serialize a "_type" and an "_id" property.  Nominally, now serializes
> an "_oid" instead of both.  (In fact, it does still serialize the "_id",
> but this is because Mongo requires such an id).
> 
> My rationale for doing this is that I wanted to get down to the simplest
> possible code if I could.  If you (or anyone else, of course), have
> deployed systems where there's a requirement to read "legacy" serialization
> formats, then we can add back in some code just to address this requirement
> (a decorator, perhaps?).  I would hope that this isn't a major piece of
> work to do.
> 
> Rob...
> Going back to last nights build, the NoSQL build failed because Mongo
> server wasn't running on the build box... I don't ever recall us requesting
> that to be set up for us, so am a bit confused as to how this used to be
> green. Any ideas?
> 
> ~~~
> I'm sure there'll be some fall-out from this, but in general I'm happy
> about how much simpler quite a lot of the code is.  In particular, I can
> see that it ought to be quite easy to make the HTML viewer stateless .. the
> PersistentRootAdapterMapping is probably not required, and we could also
> probably serialize the TransientRootAdapterMapping info into a URL encoded
> JSON stream and embed within the page.
> 
> ~~~
> Next steps... I hope to have some further time this week to work on Isis.
>  What I want to do next is to build up the "TCK" application so that we can
> get a canonical test app from which we can build some object store contract
> tests.  Right now the various object stores are tested to differing levels
> of completeness; having a TCK will make ensure a consistent level of
> quality for the current object stores, and set a target for any new object
> stores (eg the JPA object store I intend to revive, and the Cayenne object
> store that Kevin has in his back pocket some where).
> 
> That's all for now.
> Dan