At 10:52 PM 10/9/2007 -0700, Andi Vajda wrote:
On Tue, 9 Oct 2007, Phillip J. Eby wrote:
And, it is likely that for some period, we will still back-end to
the repository -- we just would go through a mapping layer of some
sort first. (And that would mean that we could do some physical
schema tuning there, without needing to mess with the application layer.)
As was said in earlier quips, Chandler was designed with an
infinitely scalable and infinitely fast repository in mind. It seems
to me that the application layer needs to be "messed with" to no
longer work with that assumption.
Absolutely! We are in violent agreement on this point. :)
However, it is not merely the assumption of infinite speed and
scalability that is a problem, but also the assumption that said
repository should persist *objects* rather than *data*. This results
in a significantly less efficient and considerably more complex and
bug-prone domain model. We have corrected a tiny piece of this with
the stamping-as-annotations change, but that is only the tip of the iceberg.
So please do not get me wrong: I am not picking on the repository
here, or even saying it doesn't fit to the app as written. It is
Chandler's architecture *as a whole* that needs adjustment; the
repository itself is almost incidental. The problem is almost more
the application's dependency on the repository, than the repository itself.
No amount of relational model is infinitely scalable or fast
either. If the app keeps its current frivolous repository use
patterns - the SideBar collections come to mind - the new model,
whatever it is, is not going to fare well. This includes a "newish"
model where we add a mapping layer between the existing repository
and the app layer.
Indeed. It is entirely possible that the domain refactoring that
Grant and I are working on will improve the application performance,
even if the repository is still in use underneath it, due to
reduction in these types of problems as a result of the domain refactoring.
However, in order to implement this refactoring, the application code
has to stop using the repository directly. That is, Chandler items
will not inherit from repository code, nor use repository
notifications to implement calculated attributes, check types, manage
birefs, etc.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
