Niclas Hedhman wrote:
More importantly, Eric Evans and Randy Stafford graciously promoted Qi4j over and over again as an interesting technology. Thanks!
Yeah, I saw some of the presentations and we were mentioned quite a lot. Excellent!
Greg Young made a very compelling presentation around "Command Query Separation", and when the videos are out, I urge everyone to look at them. I also spent a lot of time "after conf" with Greg and interesting Norwegians, discussing various interesting topics. The most interesting feedback was; Events are immutable. As they happened, they will remain forever. So in Rickard's pattern, events shouldn't be modified but instead a "compensating event" can be injected. He agreed a lot on our notions; "Commands are imperative", "Events are in past tense", "Snapshot storage isn't good" and many other things. I hope to be able to engage him in the Qi4j discussions further.
But, this is not quite what we are doing actually. We do have snapshot storages; that's what our EntityStores are for. It's just that our "snapshots" are updated for every event that happens. In Greg's version, if I understand him correctly, he basically lets the domain object live in memory, and every ten events or so he serializes a snapshot to disk, so that if he needs to read it again he will get that snapshot and apply the events after that snapshot. What we do is instead to save at every UoW complete, which is different.
Other than that I fully agree: events are immutable, and events have to be added "after the fact" in order to handle upgrades. One interesting question is whether to insert them at the time they "were supposed to have happened", or at the end of the event stream. The time of the event will then be back in time, but the construction time will be "now". I think that's the only reasonable way to do it, and reminds me of how VCS systems work, where you never change something back in time, but only apply changes to "head" to compensate.
Comments and questions after my presentation "Qi4j Persistence" were; Pros: * "Isn't this going more like 4GL with Java". * "Thanks for cutting out the non-essentials and show the Persistence bits only." * "If you didn't show the actual code at the end, I would not have grasped it. With that it all looked easy." * "The tooling (Envisage) looks awesome..."
Did you get any feedback on the actual approach? I've seen a couple of the JZ videos now, and it seems our ideas maps perfectly with what people are saying, specifically the persistence stuff from Randy, the "Is it time to ditch relational databases" and "10 architectural mistakes we won't do again" presentations. Did people get that we are providing an answer for all those things?
Cons: * "I doubt that Qi4j is useful for most applications..."
It will be useful for most domain-based applications. If you don't have a domain model there might be less use, but if you do, I don't know of any other framework that gives you as much bang for the buck. Just listen to the DDD Panel video for Eric's gripes with something as basic as values in Hibernate. SIMPLE things that people are still having trouble with. Sheesh...
* "Adoption will never happen. It is too complicated for an average programmer."
Yes and no. Qi4j covers a lot of features, but what I've noticed in StreamFlow is that as a domain model programmer there is not a whole lot you need to know to get started. We just added two more developers and they were going pretty well after just a week. Having examples to look at makes it much easier though, and I think it's mostly a matter of that: how do you best make use of Qi4j in domain model programming? What's the *least* amount that you need to know in order to get going?
Questions: * "What happen when you and Rickard move on to over things?" --> We probably won't.
I'm about to become CTO of a company working on a product, StreamFlow, that is entirely based on Qi4j, so no, probably won't.
* "We have a spatial database with coordinates. How do we do the index separation and querying for that?" --> I suggested that a custom Indexing engine that was not Fluent API capable, and only works with Named queries and directs directly to their database.
Yup, for all esoteric indexing needs, such as that or Neo4j or whatever strange things you can do with it, go with named queries and use the native indexing possibilities directly.
* "Can Qi4j deploy in an secured application server?" --> I think so, provided that the Qi4j libraries are given enough permissions.
Yes, that should not be a problem. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
