see this http://groups.google.com/group/symfony-users/browse_thread/thread/b89bcc66e3b70a59
On Tue, Mar 24, 2009 at 7:34 AM, David Herrmann <[email protected]> wrote: > > Hi Filipe, > > [email protected] wrote: > > I'm having the same problem, if you already resolve please tell. > > I haven't worked on it yet since I wrote that post, but by now I'm sure > that I will have to create a custom route handler that cuts the first > part from the route, creates the databases connection based on the cut > part and continues using the remaining part of the route as if it was a > normal sfRoute/sfObjectRoute/sfDoctrineRoute/sfPropelRoute/whatever. > > The only part I don't know yet how to do is creating the database > connection, but it can't be very hard. > > Perhaps someone else here can tell us how to modifiy a connection to use > a specific database name during run-time? > > David > > > > > On Feb 12, 11:07 am, David Herrmann <[email protected]> wrote: > >> I'm currently planning a large project where I need a quite tricky > setup: > >> > >> There is a main database holding customers and business cases. Each > >> customer may create "unlimited" business cases which are represented by > >> an actual application. The database of a business case application will > >> consist of 25+ tables. > >> > >> I want a nice URI/routing schema providing something like this: > >> > >> /:businesscaseid/module/action/:ids/:whatever > >> > >> So the route has to be parsed for the business case first, because the > >> business case holds the database connection information for the actual > >> application that comes afterwards in the route. > >> > >> I see 2 primary solutions for the database setup: > >> *) a single database for each business case as described > >> *) all business cases in 1 database with table prefixes - but I don't > >> think Doctrine is capable of inserting general table prefixes at a low > level > >> > >> Considering the multiple databases as the better option I would create a > >> basic database.yml like this (taken from the symfony+Doctrine book > >> chapter 2): > >> > >> all: > >> main: > >> class: sfDoctrineDatabase > >> param: > >> dsn: 'mysql:host=localhost;dbname=maindb' > >> username: user > >> password: secret > >> businesscase: > >> class: sfDoctrineDatabase > >> param: > >> dsn: 'mysql:host=localhost;dbname=businesscasedb' > >> username: user > >> password: secret > >> > >> I would store the actual information of the database connection inside > >> the main database, since I don't think dynamically altering the > >> databases.yml is a good idea. The action flow would then require > >> something like this: > >> > >> pre-parse the route > >> => get business case id > >> => get business case db connection from main db > >> => replace businesscase connection dbname, user and password > >> (access the settings array?) > >> => parse the rest of the route using the businesscase > >> connection as default for everything that remains > >> > >> I think I need to keep the databases apart because there might be > >> plugins or modules in the future that are only applied to a limited set > >> of business cases/customers. > >> > >> What do you think of this setup? What would be the best way to modify > >> the second database connection on the fly before the actual connection > >> is created? Where should I hook the pre-parsing? > >> > >> Would it perhaps be easiest to create a new routing class similar to > >> sfDoctrineRoute and scan for the businesscaseid in there? Then I could > >> use the standard sfDoctrineRoute features (which I would really like to > >> have). > >> > >> Or is it better to keep all database connections in the databases.yml > >> file and create them using a somehow triggered task? Then I might have > >> to adapt the model schema for each business case. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" 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/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
