First of all, congratulations!
On 28.01.2010, at 18:57, Rickard Öberg wrote:
> Hey guys,
>
> I've now posted a news item on the website, and fixed up the download links
> to the 1.0 release.
>
> The past two days I've given a couple of seminars on Qi4j in association with
> the JFokus conference in Stockholm. The seminars focused entirely on the
> issues with using POJOs for domain modeling, and how using composites and
> mixins brings a much better approach to it all. The audience was very
> familiar with what I described, and agreed with all the issues and examples I
> presented, so there wasn't much resistance to the conclusions.
>
> The main resistance is the continued reliance on relational databases for
> storage, which seems to be an issue we really need to address in order to get
> more widespread usage. Yes, it is suboptimal, yes it will be more work to
> use, but there it is. Also, several people told me not to try and base our
> RDBMS support on Hibernate, as they claimed it was basically broken in terms
> of semantics. Some horror stories were provided, and I can sympathize with
> them.
>
> So we're still back at what to do for RDBMS? Hand-coding or something like
> iBatis seems like the best option. What others are there?
>
What I am most curious about is what kind of mapping to tables one can come up
with as I cannot see how you will be able to map a domain model implemented
using the constructs of Qi4j (and keeping the current query semantics, provided
I understood them correctly) to a schema that will not lead to completely
catastrophic performance (you'll need SAP style "sizing") or will have such an
artificial table structure that reporting (IMHO the by far most valid reason
for using an RDBMS followed by the widespread availability of hosting options
that are accepted by conservative customers) will be difficult at best.
Thinking about this task (how can one build a Qi4j O/R-Mapping layer that
doesn't constrain the freedom of this brilliant framework) I came to the
conclusion that it isn't doable without on of the two (for me showstopping)
side effects, so my current take on that is, people trying to use Qi4j with an
RDBMS-based EntityStore will never be happy and should go with other entity
stores and enjoy the benefits which then hopefully outweigh the disadvantages
of not using an RDBMS (if any for a given application) or maybe I'm simply
plain wrong.
Entities composed of multiple fragments with arbitrarily complex inheritance
trees which are reused in many places in the domain model (which is for me the
big selling point of COP) and the ability to query by fragment type ("give me
any "HasName" that ...") will be a much harder (if not impossible) task to map
onto something that will fly in the relational world than to move within the
modeling constraints of JPA/Hibernate (which are _ugly_/a pain to work with, no
doubt about that). I have failed so far.
> In any case, GREAT job everyone! It's nice to have this out the door, so we
> can start focusing on how to get more people to try it out, and get more
> experience with how to best use it.
>
> /Rickard
Again, congrats on an exceptional framework and I'm curious (but not optimistic
to be honest) how you will tackle the RDBMS support without sacrificing some of
the freedom (which I suspect you won't).
Cheers,
Robert
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
