launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04508
Re: Some launchpad data model thoughts
Hi Danilo
You certainly have provided a very well thought out response - thanks!
> I agree that it would be nice if our "business logic" was split from
> basic database access layer. However, for all intents and purposes, I
> want to vouch against "more ORM-like" approach (mostly because Storm
> does allow us to get the best out of the database, and I am talking as
> someone who has seen that querying on "something" or "something IS TRUE"
> in Postgres doesn't hit the same indexes).
>
Postgres isn't the only db with this issue. I've also seen it at times
with Oracle.
I don't think a pure ORM solution is the utopia that solves all issues
(for any complex project). To me, a core goal for any software project
is to get the correct separation of concerns and well defined
architectural layers in place, along the way reducing unnecessary
coupling and dependencies. So my Launchpad-newbie view on this is that
whatever pragmatically makes sense should be considered to achieve that
business logic / persistence split. The specifics I can't really offer a
valid opinion on since I've only just been exposed to the code base :-)
Although I did say in a previous email to the list that I've found in
the past that SQL projections are very useful for loading data necessary
to populate (for example) views and this is not necessarily very ORM
like (although Hibernate does support projections via its object query
language HQL).
<snip>
>
> Compared to Java and Hibernate approach, we do have interfaces which are
> definitions of how an object would look like. And we do have both
Just a quick clarification here - Hibernate fully supports the concept
of domain object interfaces and in fact requires them to do things like
smart proxying and performance optimisations through the use of lazy
object and collection instantiation.
<snip>
lots of good discussion on Launchpad implementation details
<snip>
<>
> I am not saying it wouldn't be nice to split database model out, I am
> just saying that there's a lot more to it that needs to be taken into
> consideration before we can call out "victory!".
Indeed. I've sure got a lot to learn about the design patterns and
implementation specifics of the Launchpad code.
Thanks for providing such great input to help answer my questions.
References