launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

>>
>> As well as not querying relations that are not required, it's also key
>> to minimise the query count to get the data (attributes and collections)
>> that is required, and execute the most efficient queries possible
>> according to the underlying database's capabilities and quirks.
> 
> A small note: less queries != more efficient. More efficient is more
> efficient, and sometimes that means returning one table and then
> querying directly a related table. Query count should be /constant/
> once efficiency tradeoffs are established : but less is not always
> more.
>

Agreed, and this is what I was trying to say but clearly my wording was
unclear :-)


>>
>> I think the pseudo code which I have snipped out reflects it, but in my
>> view we also need to ensure where is a clear separation between the
>> verbs/actions and the nouns/model. eg so the bugs collection class
>> (whatever it is called - IBugCollection, IBugs, IBugManager) should have
>> methods like findUnassignedBugs() or findBugAssignedTo(IPerson) rather
>> than the apis just mentioned being on the IBug interface.
> 
> mmm, I'm not convinced either way here. I think we have room to play
> it a couple of ways.
>

I prefer it that way I mentioned because it helps keep separate concerns
in the right places. Business services should be the abstraction used to
define verbs - queries, business operations and the like - these are
then often exposed via other mechanisms such as a web service layer etc
- the higher up the stack, the increasing amount of consolidation. The
thing being modelled - the nouns - should reflect the state of the
object model and relationships between the objects but not the
operations performed on them. IMHO :-)

>>
>> One extra point I would like to make in relation to the LEP:
>>
>> "Not requiring a cache in the layer"
>>
>> In my view, we need to distinguish the type of cache we are talking
>> about. If we are talking about a L2 type cache with an object
>> lifecycle/ttl which spans individual system interactions with the
>> persistence layer and which implies the need for replication in a
>> clustered environment to maintain data consistency, then I agree that we
>> should try and avoid the need for this. However, I think some form of
>> caching within the bounds of a single interaction is useful and perhaps
>> necessary to minimise unnecessary hits on the database. The cache is
>> discarded when the interaction ends but allows objects already loaded
>> (whether via a single getById type operation or as a result of a query)
>> to be accessed from the cache if required. This is all done
>> transparently by the implementation so no explicit user code is required
>> to make it work. Hibernate uses this concept with its Session construct.
> 
> The hibernate Session lives at the ORM layer; this is above that layer
> I think : there may well be an ORM layer, but lets not conflate
> responsibilities.
> 

I was just using it as an example to illustrate the concept I was trying
to get across :-) Perhaps not the best choice.