[Gravity] add SQLiteConnection class

Review Request #83 — Created April 16, 2013 and discarded

dinos
Lunr
dinostheo:SQLiteConnection
lunr
Here is the first step of the implementation of SQL lite.
the class for query result and query builder will follow.

This depends on http://reviews.lunr.nl/r/94/
unit tests
  • 7
  • 0
  • 11
  • 0
  • 18
Description From Last Updated
We will need a SQLite3 wrapper class in order to avoid the connect on construct issue. pprkut pprkut
How do you unit test this? pprkut pprkut
superfluous pprkut pprkut
There's just way too many uncertainties about this test. How do you ensure that connect() will always work? pprkut pprkut
escape_string, when not connected, will try to connect. Yet, this is not reflected in this test. pprkut pprkut
Why not Mock the SQlite3 class? pprkut pprkut
?here does $this->logger come from? pprkut pprkut
pprkut
  1. Please rebase on top of http://reviews.lunr.nl/r/77/
  2. 
      
dinos
dinos
pprkut
  1. 
      
  2. keep this compatible with the mysql connection
  3. that looks like a very weird key to use
  4. you need to make sure this actually makes sense for sqlite
  5. 
      
pprkut
  1. There's a lot of issues solved but no new revision. Please only close issues when posting a new revision.
  2. 
      
dinos
pprkut
  1. 
      
  2. nitpick. You are trying to do the right thing, but you are drawing the wrong conclusion.
    In order to avoid the line length limit it would make much more sense to reduce the number of function calls than just introduce a (pointless) placeholder variable
    1. This method will be deleted as we already give the file to the SQLite3 object.
    2. Our db abstraction layer is not set out to work well with this scenario. The whole design of the architecture is based on "connect on demand". Now, it seems that's not possible with SQLite3. That leaves us with two options:
      
      * Pretend the "connect on __construct()" never happened.
      * Don't do connect on demand, which might have various repercussions on MySQL.
      
      Your new revision however isn't doing either of those...
    3. Woops, forgot, there is a 3rd option:
      
      * Create a simple SQLite3 Composite wrapper that allows construct() without connect.
    4. Anyway deleting it was no good option.
      I prefer to pretend we are already connected then instead of not.
    1. Yeld NULL then before having the class
    2. That's fine
  3. you can't instantiate an interface....
    1. Yeld NULL then before having the class
      same here
    2. That's conceptually fine, but you still have to do it in a way you can implement reasonable unit tests. That's not the case with the current code.
    3. Unit testing as I cannot mock the SQLite3 object...
      
    4. why can't you mock the SQLite3 object?
  4. 
      
dinos
dinos
dinos
dinos
dinos
dinos
dinos
dinos
dinos
pprkut
  1. 
      
  2. We will need a SQLite3 wrapper class in order to avoid the connect on construct issue.
    1. I didn't understand this comment.
    2. It's about what I discussed with Olivier further above.
    3. Now that we have a SQLite wrapper class can you adjust the documentation and constructor?
  3. src/Lunr/Gravity/Database/SQLite/SQLiteConnection.php (Diff revision 8)
     
     
     
     
     
     
     
     
     
    How do you unit test this?
    1. I am not. 
      This code can change with a TODO as it is to be written with the SQLiteDMLQueryBuilder
    2. You can still do reasonable unit tests with the half-implemented code. As long as it's actually testable. In this case you can't distinguish between connected and not connected.
  4. src/Lunr/Gravity/Database/SQLite/Tests/MockSQLite3.php (Diff revision 8)
     
     
     
     
     
     
     
     
     
     
    superfluous
    1. I thought we needed a Mock class as mocking SQLite3 was not working.
  5. src/Lunr/Gravity/Database/SQLite/Tests/SQLiteConnectionConnectTest.php (Diff revision 8)
     
     
     
     
     
     
     
     
     
     
     
    There's just way too many uncertainties about this test. How do you ensure that connect() will always work?
    1. The test is wrong. I know see what's going on. I will fix this
  6. escape_string, when not connected, will try to connect. Yet, this is not reflected in this test.
    1. Follow up, with the new sqlite3 wrapper class, escape_string no longer needs an open connection to escape a string. So this should be fine, as long as escape_string itself doesn't try to connect.
  7. Why not Mock the SQlite3 class?
    1. Mocking SQLite3 wasn't working.
    2. define "not working"
  8. ?here does $this->logger come from?
  9. 
      
dinos
Review request changed

Status: Discarded

Loading...