Multiple database support?
davgothic opened this issue · comments
Do you have any plans to allow idiorm to switch between multiple databases during runtime?
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.
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..
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.
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).
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?
This would be huge!
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.
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!
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".
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.
@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.
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.
@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.
I am not sure I like passing in additional parameters to be honest. It makes the API larger. I like the second option though where it is configured on the model itself.
As this is likely to appear in version two of Idiorm I am not sure it needs to be addressed right now. The code for version 2 will be a major BC break so it might make sense to wait and see how this can be best completed at the time.
I definitely like that you are dedicating some much effort to it though. Is it a feature that you require?
It's a feature I'll be using in the near future. There were many requests for it, so I thought I'd play with it.
If you don't like the additional (optional) parameters in Paris, what is your reaction to that approach in the Idiorm code attached here? Do you think I should approach it a different way in Idiorm?
I am not sure there is another way to deal with it in Idiorm in PHP5.2 and for 5.3 it would require a class extending ORM for each connection. So I agree in Idiorm it is a lot more difficult.
Saying all this though I am just leaning towards including this as you suggest with both methods for v1.* releases and then thinking how it can be designed to accommodate multi connections from the beginning in Idirom v2.
So in summary I think I may have been too hasty in what said in my previous message. My main concern is with creating parameter hell on the methods, but this seems OK in retrospect.
An implementation for Paris is now in a branch at tag/paris@fad7a4cd. It includes documentation and tests, but I haven't yet used it in a "real" project. Hopefully later this week.
Let me know if you see any concerns with it, or if you want a pull request.
Thank you for your hard work! This is looking near completion.
A couple of things:
- I am not keen on the variable naming of
$which- wouldn't this be clearer as$connection? - Same goes for
$_which_db - I prefer Mock to Dummy when naming mock objects
I haven't had a chance to run the patch yet, but otherwise it is looking good and ready for a pull request.
I missed the notification of your reply. I'll make these changes, probably next week, and follow up with pull requests.
I've started using the Paris multiple-connection code in a "real" project, and it appears to be working well so far.
I agree that $which isn't the best. I wanted something that indicated the variable wasn't a connection itself, but a label for a connection. I couldn't think of anything short and communicative. Instead of $which, I propose $connection_name (to be consistent with the extant underscore convention, although I would prefer $connectionName) for the method parameters, and $_connection_name for the instance attribute.
I used "Dummy" because that's what the original test used, but I can change both to be "Mock" easily enough.
That is great. Thank you for your continued work. I look forward to the pull request!
Closing this issue as it is now a duplicate of the pull request for the same functionality. See #76 for further details and discussion.
Yeeeeee! :) :) 👍 THANKS!
Much happy!