search

tres-framework / trestle

A database wrapper using fluent interface (stand-alone package)
MIT License
1 stars 0 forks source link

SQL standards #28

Open pedzed opened 9 years ago

pedzed commented 9 years ago

Trestle is trying to be supporting a variety of database drivers. This can only be done by following the SQL standards. Standards which are implemented in every driver we are going to support.

Commit 03f9effa, from line 323 to line 335 in particular, made me create this issue.

Things like NATURAL JOIN should not be implemented, because it's not supported in every driver we are going to support (http://stackoverflow.com/a/5147508 and http://stackoverflow.com/a/4826659).

pedzed commented 9 years ago

For the differences between each SQL driver: https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems https://en.wikibooks.org/wiki/SQL_dialects_reference

The differences aren't complete. In fact, they're missing a lot, but they might come of use.

julianrichen commented 9 years ago

So if they want to use these features they are forced to use query()? I'm not sure I agree.

We should support the universal SQL syntax but if a user needs a sql specific feature between drivers we should provide it. Maybe provide better debugging if a user attempts to use a method not support by that driver? Some of these sql specific syntax are vital to that language, for example (I have not implemented yet) but PRAGMA is rather important to SQLite where as it does not exist in MySQL (at least to my knowledge).

As we add more languages we should keep this thread in mind.

pedzed commented 9 years ago

We should support the universal SQL syntax but if a user needs a sql specific feature between drivers we should provide it.

Perhaps emulate/workaround them if applicable, but sometimes that just won't do. In that case, I'd say drop it.

One example of a workaround is ->tinyText() to VARCHAR(255) for the drivers that don't support TINY TEXT.

If somebody misses a feature, he could create a new issue and we will discuss it further. For now, I discourage adding lots of non-universal features, because if many people start using it and we suddenly decide to remove it, we have to start a whole deprecation process.

julianrichen commented 9 years ago

Fair enough, plus having all those JOINs will making maintaining a bit harder. What about:

I say keep those since they are not separate methods and effect the where()'s usability. Plus updating the class-scope $_operators is easy.