Add support for native UUID column type #1915
Conversation
Codecov ReportBase: 87.59% // Head: 88.44% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #1915 +/- ##
============================================
+ Coverage 87.59% 88.44% +0.84%
- Complexity 7832 7854 +22
============================================
Files 227 224 -3
Lines 21161 20988 -173
============================================
+ Hits 18537 18562 +25
+ Misses 2624 2426 -198
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
mringler
force-pushed
the
feature/add_native_uuid_column_type
branch
from
e7273d1
to
1dad2e8
Compare
|
Do we have a way to update docs here accordingly, so it is clear what to expect and what support across the DB types has been achieved yet? |
Not sure, the only doc for Propel 2 that I know of is at http://propelorm.org/documentation/, but I am not really familiar with it |
|
Right, we probably want to add UUID info at https://github.com/propelorm/propelorm.github.com then to be published after we merged. |
| if ($fromSqlType === 'DATE' && $toSqlType === 'TIME') { | ||
| return ' USING NULL'; | ||
| } |
There was a problem hiding this comment.
This DATE and TIME handling is dropped, why?
There was a problem hiding this comment.
The function returns USING NULL per default, so this was just an extra step to get to the same result.
|
Small conflict then we should be good to go |
|
Oh, hadn't realized, thank you for the notice! |
mringler
force-pushed
the
feature/add_native_uuid_column_type
branch
from
46dc313
to
1db89c3
Compare
As discussed in #1914, this allows to use
UUIDas column type in schema.xml. Underlying columns are set to the native uuid type of the database system (uuidin Postgres and Oracle,UNIQUEIDENTIFIERin mssql). In Mysql/MariaDB and SQLite, an error is thrown. Inside the model and query classes, the uuid columns use string values.This is pretty straight forward, a new type literal is registered and associated with strings, and register the type in the vendor adapters with the corresponding type. For Postgres, I added cast statements used during migration. Tests check generated
createandalterstatements and internal mapping of uuid to string.I have played around with it on Postgres, and it seems to work there.
I also added a commit with two fixes for the test setup scripts:
setup.mysql.shalways used "test" as database name, even though the fixtures are build using an environment variable ($DB_NAME) with "test" only as fallbacksetup.pgsql.shsome statements failed when a variable was empty, leading to empty string parameters