Page 1 of 1

Reasons to load driver dynamically

Posted: Wed Apr 26, 2006 8:15 pm
by alex.barylski
In an abstraction layer, like say AdoDB

Would you ever need the ability to do change drivers dynamically, say switching from MySQL to MSSQL during runtime?

This only thing I can think of would be in format conversion...

Load a mysql driver, list results for a table (SELECT *) and serialize that array to a MSSQL data store.

Other than this, I can't really think of a reason why dynamically linked drivers would be required...

Input?

Cheers :)

Posted: Wed Apr 26, 2006 9:08 pm
by nielsene
Along the same lines as the format conversion you listed, various replication strategies could also require switching or mutliple drivers.

Some testing strategies could require intercepting the flow to the database at different points and subsituting a different database, possibly even a different driver.

You might have some sort of failover strategy that would requiring changing from your Oracle DB to a backup PostGreSQL; if keeping a homogenous cluster was either too inexpensive or deemed too great a risk, etc.

Albeit all of these are rather "out-there', but....

Posted: Wed Apr 26, 2006 10:32 pm
by alex.barylski
nielsene wrote:Along the same lines as the format conversion you listed, various replication strategies could also require switching or mutliple drivers.

Some testing strategies could require intercepting the flow to the database at different points and subsituting a different database, possibly even a different driver.

You might have some sort of failover strategy that would requiring changing from your Oracle DB to a backup PostGreSQL; if keeping a homogenous cluster was either too inexpensive or deemed too great a risk, etc.

Albeit all of these are rather "out-there', but....
I was thinking of implementing a dynamically loadable driver, but the fact is, the most obvious...(data store conversion) could be done without the over head of DLD, by simply storing data in a temp session like:

1) Script start, Open connection, (SELECT *) and store results in array
2) Serialize array, Script complete
3) Script start, Open connection, Unserialize array and store native array in new data store.

The functionality is still available and easy enough to implement, but you don't need the over head of DLD connecting "dynamically" to a data store...seeing how this operation is quite frequent as opposed to data store conversion, it makes sense to keep the binding static.

Opinions, Arguments, etc...?

Cheers :)

Posted: Thu Apr 27, 2006 12:01 am
by Christopher
I have never really understood the Factory style DB interface layers. They just add overhead without providing much real-world benefit. Like the examples you give above -- what you would really do would be to just create two connnection objects.

Posted: Thu Apr 27, 2006 12:15 am
by alex.barylski
arborint wrote:I have never really understood the Factory style DB interface layers. They just add overhead without providing much real-world benefit. Like the examples you give above -- what you would really do would be to just create two connnection objects.
I can't say I've even seen that approach used, but when writing my own abstraction layer, it was an approach I did consider.

Excellent content for my article though, didn't even think of making note of that...

By factory style I assume you mean creating an object of "driver" type as opposed to always creating a object of "fixed" type?

It doesn't make sense in most cases, as by definition, an abstraction layer would require some common properties of everything it abstracted, thus you would likely be able to provide a consistent API in the abstraction layer and not require anything specialized in the driver layer.

However (although I can't htink of any example now) I am sure there are times where derivation would work better over dynamic driver loading via connect() or similar...

Like I said earlier...object discovery & analsys...being able to determine if an object is truely a is_a or has_a relationship to another object is almost an art onto itself :)

Real programmers are the Davinci's of the binary world...

Too bad I'm not Italian :P

Cheers :)

Posted: Thu Apr 27, 2006 7:53 am
by dbevfat
Hi,

I've used this with some data-migration scripts and even once when I had to insert data into two different databases (don't ask). It came in handy. Also there was one (exactly one) time in my life, when I had to port a project from one DB to another. A simple change in the configuration and a few changes (very few, since I stuck with ANSI SQL) in the queries, and that was all. This time, I really appreciated AdoDB.

And why not a factory? It creates a connection of some type. By making it a factory, you have flexibility (which I for example needed, but most don't) and ease of use (like: database type is a string from a config file). It's as high as you can get up (abstraction-wise) and still have all the flexibility you need. I don't see any issue here.

About the overhead; you have to include the mysql classes in both cases anyway. It comes down to including files, I guess. There is not significant difference in execution performance. With a DBA-Layer, you have some additional files, but I don't think one should really pay attention to these. Premature optimization. ;)

Regards

Posted: Thu Apr 27, 2006 10:14 am
by alex.barylski
About the overhead; you have to include the mysql classes in both cases anyway. It comes down to including files, I guess. There is not significant difference in execution performance. With a DBA-Layer, you have some additional files, but I don't think one should really pay attention to these. Premature optimization
I'd normally byte, but seeing how I'm not clear on what it is your saying...I'll only nibble... :lol:

Get it? Byte...N(i|y)bble?

Har har har...

What are you saying? I can't speak for Arborint, but I wasn't advocating the non-use of abstraction layers, as they are a good idea, as any abstraction usually is when designed right.

What I was saying, was both why and when one *might* consider using derivation for an abstraction layer over static invocation...but I thought the answer as to why it might be a bad idea (unless absolutely mandatory) was explained in my first response...

Cheers :)

Posted: Thu Apr 27, 2006 11:50 am
by Christopher
dbevfat wrote:And why not a factory? It creates a connection of some type. By making it a factory, you have flexibility (which I for example needed, but most don't) and ease of use (like: database type is a string from a config file). It's as high as you can get up (abstraction-wise) and still have all the flexibility you need. I don't see any issue here.
My point about the Factory design in many DB abstraction layers is that they exist for the developer of the abstraction layer -- not the user. 99.9% of the time only one type of database is ever requested from the Factory. A Factory that only needs one option is unnecessary in my book. The developers create Factory because from their point of view they are providing multiple interfaces -- but they are not really used that way.
dbevfat wrote:About the overhead; you have to include the mysql classes in both cases anyway. It comes down to including files, I guess. There is not significant difference in execution performance. With a DBA-Layer, you have some additional files, but I don't think one should really pay attention to these. Premature optimization. ;)
It's not performance overhead I was implying. It is really design overhead.

Posted: Thu Apr 27, 2006 1:31 pm
by dbevfat
I should've paid more attention when I read and replied this - I think I rather misunderstood you both, at least in some aspects.
Hockey wrote:I'd normally byte, but seeing how I'm not clear on what it is your saying...I'll only nibble... Laughing

Get it? Byte...N(i|y)bble?

Har har har...
;)
arborint wrote:My point about the Factory design in many DB abstraction layers is that they exist for the developer of the abstraction layer -- not the user. 99.9% of the time only one type of database is ever requested from the Factory. A Factory that only needs one option is unnecessary in my book. The developers create Factory because from their point of view they are providing multiple interfaces -- but they are not really used that way.
I see. But other parameters, such as username, password, schema and possibly charset must be passed to it anyway. In adodb, all that becomes a string in an URL-like form. Strictly speaking, the database type has nothing to do with connection data, but it doesn't really cause much confusion when all is stored and used together. So (in adodb) the factory actually has more options, not just database type.

But, to be honest, there is no real difference between:

Code: Select all

$connection = ConnectionFactory::create('mysql');
and

Code: Select all

$connection = new MySQLConnection();
It's not performance overhead I was implying. It is really design overhead.
Valid point then. But such is the thing with packages that are designed to satisfy different opinions, aproaches and needs.

Regards

Posted: Thu Apr 27, 2006 4:27 pm
by Christopher
dbevfat wrote:But, to be honest, there is no real difference between:

Code: Select all

$connection = ConnectionFactory::create('mysql');
and

Code: Select all

$connection = new MySQLConnection();
Valid point then. But such is the thing with packages that are designed to satisfy different opinions, aproaches and needs.
I agree with you and my main objection to the use of a Factory for DB libraries is that there is a subtle difference between the two lines above -- at least for me. The top line says to me that I just change the type passed and everything will just work. The bottom lines says to me that I am dealing with a whole different class, which though polymorphically compatabe, may cause me to do some additional porting work if I change. If the library does in fact deal with everything then a Factory sends the right message. If not (e.g SQL may need to be edited) then I prefer to be clearer about the possible effects.