On Jul 2, 2:13 pm, Jonas <[EMAIL PROTECTED]> wrote:
> With SAContext each model can live in a different database but when
> you scale big there are all kinds of ways things might need to be
> partitioned:
>
> * Some data gets accessed all the time while some other data is only
> ever written.
this falls under the concept of "clustering". For clustering, there
are some simplistic techniques which can be used right now, namely to
bind your session to a different connection depending on which
database you'd like to use for a particular operation. To do that,
create your session, bind it, then attach it to whatever you are using
to track your session; in this case i think the "session" attribute on
SAContext sticks it thread-locally on the underlying SessionContext.
>
> * You could want that certain records are in certain databases. E.g.
> users 1 to 1,000,000 , or news/articles/information stored by year.
this falls under the concept of "sharding". We have a ticket in trac
that basically says, "start thinking about sharding". even the best
sharding implementations (like hibernates, and whatever Twitter came
up with) are extremely limited; with SQLAlchemy, theres not too many
ways to make this work with any degree of ease right now (other than,
of course, pre-identify the appropriate database and attach your
session to it). we have an elaborate notion of how we might want to
do it, involving a series of plugins at the ORM and SQL levels.
Suffice to say its way out of the scope of a convenience tool like
SAContext...although if we do get it working, SAContext would still be
usable as always.
also, the strategy used for "sharding" will lend itself equally well
to automatic "clustering" scenarios too, since its essentially a
configurable rules engine that states which engine should be used for
a particular operation.
>
> * To use a separate database for each application that you mount
> within the server. E.g. for a multi-blog application
Yes, you use the SessionBoundStrategy and ensure that the SAContext
binds its session to the appropriate engine at the start of each
request. If your multi-blog talks to multiple databases, you bind the
session at the table/mapper level individually.
One super important thing to note is: *none of this has anything to
do with SAContext*. this is all just a product of being aware of how
the Session works (including its ability to bind to engines overall,
per-mapper, per-table), how a MetaData works with regards to binding,
as well as the SessionContext plugin, which literally is nothing more
than a thread-local variable.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
