[Chandler-dev] [Sum] The Great Architecture Discussion of 2007

[Phillip J. Eby]

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.