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
