silktide / reposition-sql

SQL module for reposition

reposition-sql

SQL module for reposition

reposition-sql's Issues

Approach discussion

So, a few quick points regarding our approach to the abstraction.

When using Postgres, if you have a differently named sequence than one that is auto-generated by the column name, then it'll silently fail to return the ID.

The source code for this involves generating a sequence ID regardless of your database type and feeding it into the PDO lastInsertId function.

Postgres will listen to it and apply it to a sequence, MySQL will ignore it and just run the lastInsertId() as it always has. I have no idea what other databases will do.

As this code has no knowledge of what type of database we're actually connected to, I feel we're at the mercy of code we have no control over and we have to potentially make non-intuitive code where we could simply send the code down different paths depending on our knowledge of different databases.

So, I'm not sure how clear that was, but here are a few topics of discussion about reposition that I feel are quite pertinent:

Errors

The lack of getting an error back saying that it didn't get a sequence ID would make non-Danny based debugging a code trawl. I'm not sure whether it should throw an exception by default, but at the very least I feel there should be some debug mode I can enable for reposition that'll throw me some errors.

At the very least, I think we should get some logging in there, which we can hook into Monolog (which we need to have a more generalised discussion about I think).

Strengths and Weaknesses

Abstracting to this level has some disadvantages in that we take away some of the inherent advantages each database can give us. A key example of that (in my eyes) would be the ability to do insert in a non-race condition'y way using the Postgres RETURN VALUE stuff. Others include potentially being able to do other queries that are vastly syntactically different but useful (so, the ability to do UPSERT in both Postgres + MySQL for example)

Multiple Repositories

Most of the things that are above can be handled under the hood just with the code having an understanding about what it's trying to assemble code for. If putting switches and custom driver logic in the reposition-sql is there a case for having a base reposition-sql that they all include, and then having specific repositories for each database we support that map queries to custom logic based on your database engine?

bug mixing includes and joins

Currently, if you include other entities while also joining to other collections, the find interpreter treats all joins as separate entities, contrary to the expected outcome

Test case is joining to the intermediary table of a many to many via join() rather than include(), so it may be picking up on the relationship automatically

Limit queries and includes are broken

If a where clause references fields in an included relationship, the limit subsquery will join on zero records (as the included fields will all be null).

I think we have to suck it up and accept that limit queries can't be reliably done with reposition. We will have to resort to limiting by the number of entities in the resulting collection, as part of the hydration system.

Refactor how driver specific attributes are set

Due to the stupidity of the PDO group, the constant PDO::MYSQL_ATTR_USE_BUFFERED_QUERIES has the same numeric value as the constant PDO::PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT. The latter is deprecated in PHP7 and is throwing warnings

A possible solution is to inject an $options array instead of $useBufferedQueries, which contains arrays of options keyed by the DB driver name (mysql, pgsql,etc...). This would allow for attributes to be set only if they were specific to the drivers.
In this solution, we would also need a default key for attributes that are independant of driver (such as PDO::ATTR_TIMEOUT or PDO::ATTR_PERSISTENT)