Create Adapters for more refined multiple database experience

[eman1986]

I built the first step in making this PDO wrapper more diverse and I'd like to proceed with phase two.

Phase two would create database-specific adapters to help combat a couple problems encountered from phase one.

Bad news, it would add more files to the wrapper library. Good news, it'll be 100% database agnostic and it will not break any current installs.*

I'm seeking your approval of such an overhaul, I'll still do it but if you prefer not to have it in your main repo, I'll just keep it on my fork and can just be an alt version for those who want it (such as myself ;)).

*as long as they include the adapter to the database their using, so minor code change will be needed depending on how the programmer added the library.

[mikehenrty]

So, I am currently aware of the differences in LIMIT syntax from your earlier commit. What are the other driver specific differences you are looking to address? Do these changes require new files, or are the differences small enough (as in the case of LIMIT) that we could just put 'if' statements in the existing code when we need to generate different queries based on driver? If it does require separate files, can we still leave the external API the same, meaning can we have the users still import the same file as before, and only internally use these other files?

Once again, thank you for helping to improve this library!

On Apr 2, 2013, at 12:57 PM, eman1986 notifications@github.com wrote:

I built the first step in making this PDO wrapper more diverse and I'd like to proceed with phase two.

Phase two would create database-specific adapters to help combat a couple problems encountered from phase one.

Bad news, it would add more files to the wrapper library. Good news, it'll be 100% database agnostic and it will not break any current installs.*

I'm seeking your approval of such an overhaul, I'll still do it but if you prefer not to have it in your main repo, I'll just keep it on my fork and can just be an alt version for those who want it (such as myself ;)).

*as long as they include the adapter to the database their using, so minor code change will be needed depending on how the programmer added the library.

— Reply to this email directly or view it on GitHub.

[eman1986]

the interesting thing about the limit restriction, its not so simple.

SQL Server's limit syntax is SELECT TOP 5 * FROM someTable;

Oracle is much worse since they don't have a limit syntax but an odd row count logic you have to do.

on postgres they have limit but if you want to use the offset (mysql does limit 10,0) postgres does that differently.

I would code it so that it would work with minimal disturbance to the user as the pdo wrapper will be looking for the adapter and the user just has to upload the adapter to the database their using.

[mikehenrty]

Sounds good man. Let me know if I can help out in any way. Thanks again!

On Apr 4, 2013, at 6:15 AM, eman1986 notifications@github.com wrote:

the interesting thing about the limit restriction, its not so simple.

SQL Server's limit syntax is SELECT TOP 5 * FROM someTable;

Oracle is much worse since they don't have a limit syntax but an odd row count logic you have to do.

on postgres they have limit but if you want to use the offset (mysql does limit 10,0) postgres does that differently.

I would code it so that it would work with minimal disturbance to the user as the pdo wrapper will be looking for the adapter and the user just has to upload the adapter to the database their using.

— Reply to this email directly or view it on GitHub.