Multiple database support?

[davgothic]

Do you have any plans to allow idiorm to switch between multiple databases during runtime?

[j4mie]

This is tricky. Idiorm was designed to be simple, and to cater for 80% of use cases without being highly specialised for the other 20%. I'm sure that more than 80% of web applications are running on a single database connection. I wouldn't want to clutter the API to support something that few people will use.

Having said that, I do have some ideas about how this could be implemented. I'll keep the feature request open and consider it. If you can provide any more details about your requirements, that would be really helpful.

Thanks for the suggestion.

[unirgy]

I just came here to see if anything planned to maintain multiple connections simultaneously, for example having one for writing to master and another for reading from slaves (ex. round robin DNS). Paris would have to be involved as well..

[unirgy]

I've implemented multi-db support in my framework:
http://github.com/unirgy/buckyball

Classes BDb, BORM, BModel, lines 659-1024

The implementation is specific to read/write connections, but shouldn't be that hard to make a generic implementation in the lib itself.

[kilokeith]

This would be huge for me. I'm really loving Idiorm as an slim ORM, and it's the only simple one out there that runs on php 5.2.

I'd settle for being able to extend or make a new instance of ORM, then being able to pass that to a Paris model ($this->set_orm($orm)). It would require some changes to the structure of Idiorm, but shouldn't affect the codebase at large or any implementations.

A big +1 to this suggestion.

We've got a common database with users and groups tables and a set of application-specific databases with application preferences, configuration, etc. Having multiple database support built into Idiorm & Paris would be great for us.

As it is we've gone and modified our Idiorm & Paris to support a $_database_name property in our Paris classes - it's a bit of a hack though. If it's not something you're inclined to add we'd still be interested in hearing your thoughts on how best to implement it so we can improve ours (and contribute it back to the project if you so wish).

[inversion-of-control]

First of all, thanks for the fantastic work! I mainly use Paris / Idiorm with Silex to create RESTful APIs - the power of these combined libraries is just mind-blowing in terms of productivity and elegance.

For my own projects, I only ever use PHP 5.3 (eagerly anticipating 5.4 to hopefully banish my remaining PHP woes) and have refactored Paris / Idiorm to support namespaces (through a simple late static binding fix) and phar / autoloading.

For me, the ability to switch between multiple databases (JOINs across databases is obviously an even more complex beast) would be the icing on what is already a very tasty cake. Anyone interested in discussing above topics further?

[lawrencegs]

This would be huge!

[ShawnMcCool]

I began using Idiorm in a project but pulled it 10 minutes later due to the lack of multiple connection. I considered hacking it in but there's just no time. Anyway, I don't expect you to change your software because it wasn't perfect for one project I worked on. But, I'd prefer to use Idiorm when I can.

[ljgww]

Just stepped on this issue. I'd add +1 for multiple databases feature. I work mostly with sqlite. As kilokeith suggested, I'd be happy to have multiple database objects, and switch between databases. And, yes, multiple db variant shall be different library set to retain existing library in its purity.

I also love simplicity and elegance of these two libraries. Respect!

[ljgww]

When thinking through this issue, I have came to a question: Do idiorm use any session persistence facilities?

I am asking this, because theoretically every PHP page is anew code session. It is possible to use more than one database on different pages unless there is some "session persistence".

[chebizarro]

This would be an enormous boon for me without adding much in the way of complexity. My need is much the same as other posters - I have a database which, for a number of reasons including contractual - my application cannot alter. I would like to be able to use another database to store information about entities in this read-only database.

[tag]

@treffynnon, after going through the code, I think it would be easy to work this into ORM in a backward-compatible way, by treating the ORM as a facade to a hashmap of db references. ... Even the way query logging is set up supports this.

In other words, store prefs, the PDO connection, etc., in named keys within ORM (using the name 'default' if no key provided). With only one connection, no one would know, and using different connections would simply require passing the connection name....

Do you want me to go ahead and code this approach? I'll have some time this week, and when done, will make sure multiple connections are working in Paris as well.

[treffynnon]

Sounds like a good plan to me. Thanks!
On Nov 23, 2012 8:47 PM, "Tom G" notifications@github.com wrote:

@treffynnon https://github.com/treffynnon, after going through the
code, I think it would be easy to work this into ORM in a
backward-compatible way, by treating the ORM as a facade to a hashmap of db
references. ... Even the way query logging is set up supports this.

In other words, store prefs, the PDO connection, etc., in named keys
within ORM (using the name 'default' if no key provided). With only one
connection, no one would know, and using different connections would simply
require passing the connection name....

Do you want me to go ahead and code this approach? I'll have some time
this week, and when done, will make sure multiple connections are working
in Paris as well.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-10669382.

[tag]

@treffynnon, I've spent some time thinking about how to accomplish this in Paris. There are two approaches, and I think implementing both is the way to go. First, permit an extra parameter to Model::create() and ORMWrapper::for_table(), similar to the commit above. Second, similar to the existing public static properties (::$_table and ::$_id_column), add a third one: ::$_connection_key. This approach was called "hacky" in one of the related issue tickets here (but I can't find it now), but might have the consequence of permitting use of has_many(), etc. across connections. It would take some testing to be sure. As I said, I think applying both approaches is the best.

Do you have comments about how I should proceed?

To make things slightly easier, I'd like do 5.3+ only, if that's okay.