The identity and visit stuff is pluggable, i.e. you can replace the existing
components without hackery; just write your own and specify which one to use in
the application .cfg file. This probably sounds more intimidating than it is;
the code is really pretty straightforward and you can use their implementations
as a starting point.
You might consider using a single (separate) database to store all visit
information for *all* the customers combined. Your visit schema could have an
additional 'customer' column to distinguish which database to use for
everything else.
Barry
----- Original Message ----
From: Michael Bayer <[EMAIL PROTECTED]>
To: sqlalchemy@googlegroups.com
Sent: Thursday, May 8, 2008 5:05:22 PM
Subject: [sqlalchemy] Re: Multiple SQLAlchemy DB usage in TurboGears
On May 8, 2008, at 11:15 AM, Bobby Impollonia wrote:
>
>> I'd try bypassing their SQLA integration altogether if thats possible
>
> It isn't possible if you are relying on the turbogears identity system
> (cookie-based visitor tracking and access control).
that sounds like a particular set of mappings and classes. theres no
issue using those; I was talking about their Session integration.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
