Thanks for such detailed answer Michael.
On Tue, Oct 14, 2008 at 5:20 AM, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
> On Oct 13, 12:14 pm, "Tomasz Nazar" <[EMAIL PROTECTED]> wrote:
>> 2) SQLAlchemy 2nd level cache
>>
>> That is most frustrating for me coming from Hibernate, where it's
>> built in. You may point to memcached or whatever, but the truth is it
>> improves performance and coding style hugely!
>> I would love to optimize later and be a bit lazy.
>> Maybe the authors do not have resources -- it's a great soft anyway --
>> but that should be one of the 1st features on the roadmap.
>
> .... pull from the giant vat of identifiers when needed. This was one of
> the original issues SQLA sought to solve, and makes it a whole lot
> easier to load several levels of objects, with or without a LIMIT/
> OFFSET applied to the overall results, with only one round trip.
I started to play with SQLa joins and 'add_entity' feature lately, so
if I would get all objects in one query that would be not so bad.
However, to do that one needs to learn SQLa query language a lot, and
build some advanced queries (and there aren't lots of examples in the
documentation :( ).
And also with 'add_entity' I loose my OO, and relations between
objects. Query result is not just a list of objects, but a touple of
all the different objects from the query...
Or one can write custom SQL query instead of SQLA query. Then we have
a list of kind of DTO objects. Also not that pretty.
Both ways (I use them) but have disadvantages.
Having 2nd level cache would allow a developer to write short and easy code.
I could write basic SQLA queries for objects and iterate through their
relations (even when few levels deep).
Of course, for the first time it would take long to hit DB with many
queries, but -- with cache -- further requests do not exist, cause
cache is hit instead.
That has advantage in early (even after 1 year) stage of project, so I
do not have to worry about fancy SQL queries or about learning SQLA
query language. I worry more about other stuff (understanding business
domain, etc..) So as developer spend precious time elsewhere.
Also code would be a lot simpler:
confs = dbsession().query(Conference).filter(XXX).all()
%for conf in confs:
${conf} ${conf.author} ${conf.author.phone} .... etc...
It's that simple with cache being used.
Without that... code is more complicated.
> But eager loading isn't as good as no loading at all - so onto caching
> for SQLA. There's some reasons they're inconvenient. ORM mapped
> objects usually need to load additional data (i.e. lazyloading) which
> implies an association with an active database connection. Caching
> the ORM objects means you have to dance around all the lazy loaders to
> ensure none fire off, since there is no active database connection -
> furthermore, even if you re-associated them with one, now you have a
> concurrency issue.
>
> Secondly, its incredibly common to get some ORM mapped objects from
> somewhere and start using them in a transaction. If you get them from
> a cache, again you lose because they're global objects - you can't map
> them back to your transaction. So ORM caching which seems very simple
> and automatic quickly leads to some very broken use cases for those
> who don't understand what they're doing.
I'd live with that. I mostly need cached objects for read-only view
layer, to iterate over objects and their relations..
Hibernate guys did that and I didn't had any problems with that cache.
For updating object from cache, I will load it from db anyway (or merge).
> Pylons and Mako offer some of the most flexible view level caching
> around - you can cache controller methods, functions, template
> renders, and individual components (defs) of templates. I recently
> just wrote a small <%def> which sits in the globally inherited layout
> template, wraps the middle of the page in a conditional cache which is
> enabled and configured by a method called in the controller - so that
> context-sensitive info in the header (like login info) stays context
> sensitive, the content-heavy middle is optionally cached, all the
> parameters and zoning of the cache is configured at the controller
> level, the ORM fetches data purely from the DB (but less often), and
> none of the templates have any idea whether or not they're cached or
> for how long. This is likely the subject of my next Pylons/Mako blog
> entry.
I was thinking about your idea of caching view layer, instead of
having 2nd level object cache.
Yes - it is new for me. In Java it might be it is not so common.
I will give it a try..
Please, do write a blog then. It would be nice to listen to.
With examples please :)
T.
--
_i______'simplicity_is_the_key'__________tomasz_nazar
_ii____'i_am_concern_oriented'________________JKM-UPR
_iii__'patsystem.sf.net'___________________linux_user
_'aspectized.com'___________________________prevayler
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
