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 -~----------~----~----~----~------~----~------~--~---
