[DBAL-1257] doctrine-dbal will not execute if doctrine/dbal is installed as a dependency Created: 30/Jun/15  Updated: 30/Jun/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.5.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Matthew Turland Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal


 Description   

doctrine-dbal is configured as a vendor binary. However, when doctrine/dbal is installed as a dependency via Composer, while doctrine-dbal is copied to vendor/bin, the doctrine-dbal.php file it requires is not. As such, doctrine-dbal won't work if invoked in this situation.

doctrine-dbal should probably check if doctrine-dbal.php exists in the same directory and, if not, instead include it from __DIR__ . '/../doctrine/dbal/bin/doctrine-dbal.php'.



 Comments   
Comment by Christophe Coevoet [ 30/Jun/15 ]

Composer will never copy bin files, as this would indeed always break any requirement in them (which would involve copying the whole library too). It either creates symlinks or create proxy files calling the original one, depending on your system. In both cases, the doctrine file stays in its place, and so everything works fine.

I also see 2 reasons which could break things:

  • if you have a tool replacing the files generated by Composer by their own files and doing it in a crappy way => solution: stop using this tool until they fix their mess
  • if you have a broken setup advocating it can create symlinks but then actually copying files (I think this may happen in some cases with VMs when you are in shared folders, but I'm not sure) => solution: fix your system.

In any case, there is nothing which should be changed in Doctrine DBAL IMO, as DBAL works totally fine for the expected Composer behavior.
Thus, your proposal would not work for people moving their composer bin-dir to a custom location, so it is not even an acceptable workaround.





[DBAL-1256] SqliteSchemaManager do not found type of tableColumn if contain whitespace Created: 28/Jun/15  Updated: 28/Jun/15

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.4.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Hermann Bernwald Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, schemamanager, sqlite

Attachments: Text File output.txt     Text File SqliteSchemaManager.patch    

 Description   

source:
https://www.fuzzwork.co.uk/dump/sqlite-latest.sqlite.bz2

input:
CREATE TABLE certSkills (certID integer DEFAULT NULL, skillID integer DEFAULT NULL, certLevelInt integer DEFAULT NULL, skillLevel integer DEFAULT NULL, certLevelText VARCHAR (8) DEFAULT NULL, CONSTRAINT id PRIMARY KEY (certID, skillID, certLevelInt, skillLevel, certLevelText));

command:
doctrine:mapping:import

output:
Unknown database type varchar requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it

solution:
add trim() to $tableColumn['type'] = $parts[0]; in SqliteSchemaManager line 248






[DBAL-1255] [GH-875] Generating a ColumnDiff led to unquoted Columns for Postgres Created: 28/Jun/15  Updated: 28/Jun/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of tk-s:

Url: https://github.com/doctrine/dbal/pull/875

Message:

Postgres needs (or understands) quoted column-names all the Time, especially if one is using mix cased column names.
While generating Diffs, the old column name got no quotation.






[DBAL-1254] FIX TINYINT(1) - Make BOOL use BIT Created: 27/Jun/15  Updated: 28/Jun/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2, 2.2.1, 2.2.2, 2.3, 2.3.1, 2.3.2, 2.3.3, 2.4, 2.3.4, 2.5, 2.4.1, 2.4.2, 2.4.3, 2.3.5, 2.4.4, 2.5.1
Fix Version/s: 3.0
Security Level: All

Type: Improvement Priority: Minor
Reporter: Jonathan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

All environments


Issue Links:
Reference
relates to DBAL-781 Doctrine maps tinyint with length > 1... Resolved

 Description   

1. MySQL doesnt have boolean type but it supports BIT(1) which in my more novice opinion would be more effective if you wanted to use something to map. OR just not made a boolean type. Ideally, a programmer would go I am using the MySQL database engine, no boolean, let me use a TINY INT. So instead of making the programmer think you dumbed down a field that can store 255unsigned valyes into one that stores TRUE OR FALSE.

2. Now I need to use 2 bytes of data to store the integer 2-255unsigned in smallint. So think about all of the fields that could use TINYINT to store configurations or settings where there is more than a true false. Account types, account status, day of week, day of month, current AGE, date at death, age required to do XYZ, You do not offer enum and you made a strong tiny integer into a weak bipolar newborn.

3. By requiring two bites of data to these fields you will be double the data storage in probably 1 out of 5 of my columns. If you had a million records with this issue that is an extra 1MB of unneeded database size. This may slow performance of select and other MySQL operation fractionally.

4. In summary, you spoon fed developers a weak FAT bipolar newborn. Give us back out functionality, allow us to trim down and NORMALIZE properly, stop cross-mapping data types. You take away all enum options. This is ONE major major major major benefit of Propel is that they at least have TINYINT. Also: built in behaviors versus complaining that its too hard to test and maintain behaviors. I respect Doctrine and chose it for its stability and strength. Everyone makes mistakes but please fix this one. Sorry in advance for being rude but I preferred being honest versus being a suck-up.

Love your application, thank you very much for being SRP friendly(data mapper) stable 2.x, part of symphony install by default/massive tutorial/knowledge base online, more contributors, active contributors, ROADMAP(they refuse to use one in PROPEL), easier to unit test. I spent weeks reading every word about both. Thank you for listening.

I decided to post this as an issue and left the comment on (http://www.doctrine-project.org/jira/browse/DBAL-781) so others searching for this issue would realize other people have this frustration and it is not just them. Also everyone was searching online for a list of comparable to Propel benefits so I added that in for a little SEO love.



 Comments   
Comment by Marco Pivetta [ 27/Jun/15 ]

By requiring two bites of data to these fields you will be double the data storage in probably 1 out of 5 of my columns. If you had a million records with this issue that is an extra 1MB of unneeded database size. This may slow performance of select and other MySQL operation fractionally.

I'd rather say that it is very unlikely to use the ORM in a context where 2 bytes per record makes such a huge difference.

I generally agree with the enhancement proposal (which cannot be implemented in 2.x), but I disagree with the fact that using a small integer is a problem there (we chose it for portability first).

As for ENUM s, it is a bad idea to have them anyway: http://stackoverflow.com/questions/8750724/what-do-you-use-instead-of-enum-in-doctrine2/9057352#9057352

That said, moving to BIT is a good idea for 3.x, which I'll add to the resolution versions.

Comment by Jonathan [ 27/Jun/15 ]

Thank you for setting in motion a change to give me the power of TinyINT back.

It is not 2bytes per record, it is 2 bytes PER column PER record. There is some tables where I may have 3 or 4 or almost all of the columns in (settings tables) that are all TinyINT. Just a concern for performance as that was one of the comments mentioned about a Doctrine weakness.

Ideally you would just map incoming booleans to a char(1) and not run into the same problem we have here with bit since bit supports long bit strings as well as short. However, that is more edge case than TinyINT at least for me. There would be no outgoing boolean and map TinyINT outgoing to whatever would be good for the accepting new database type.

Again, anything to give me a Doctrine TinyINT. Also, please consider behaviors. Thank you.

Comment by Marco Pivetta [ 27/Jun/15 ]

It is not 2bytes per record, it is 2 bytes PER column PER record. There is some tables where I may have 3 or 4 or almost all of the columns in (settings tables) that are all TinyINT. Just a concern for performance as that was one of the comments mentioned about a Doctrine weakness.

I still don't see the massive overhead that you are seeing here
The ORM would still be more overhead than all of this composed.

Comment by Jonathan [ 28/Jun/15 ]

1. Stop comparing ORM to DB performance. Each layer should be optimized separately. Unfortunately you have removed this performance encapsulation ability with only supporting half of MYSQL types. Everyone that tauts doctrine versus Propel, and including even in your own documentation it talks about best practices, and about highly optimized systems, SOLIDoop, SRP, etc, etc. However you think it is okay to DOUBLE the storage requirements of a column for no reason. Heres an analogy: Thats like paying for two parking spots for your car when you only need 1. Also since you read into memory every byte when doing any table lookup or disk reads then you are not just double storage, you are doubling EXPENSIVE memory and processor loads due to buffer size.

2. Also, if the ORM is a slow pig. I need my database to be a fast horse. EVERY single optimization tutorial says use the SMALLEST datatype possible for your requirements.

3. MySQL has a bool/boolean name alias for TinyINT (Just read more on this because I want the best solution in future and I am willing to help with research and suggestions to keep an amazing project stay amazing.) You can use this in your mapping set so when you have incomming boolean mappings they get converted to MySQL. If they are converting away from MySQL to something like Oracle or Postgre they will have bigger things to worry about then converting TinyINT types to booleans and in this case. The problem is an incompatability outside your control. This allows the use of boolean incoming imports that map to TinyINT as you have before and it is Native. Also you can still many TinyINT directly. This prevents the cross-mapping anything. Also it leaves the design in the hands of the database designer. Remember encapsulate responsibilities.

4. Your arguement ONLY makes sense for NDBcluster storage engine as all NDB data storage is done in multiples of 4 bytes so TinyINT,SmallINT,MediumINT,INT are all the same storage.

5. However, when I have to double so far 1 in 7 colums size and I am not using NDB. I become concerned about performance from the database besides the performance encapsulation issue.

6. Using one problem to answer another is not beneficial. It is analogous to answering a question with another question.

7. Thank you in advance for your replies, your open willingness to listen and your active integration of my suggestions into doctrines future. It is a major confidence builder in the project.

Comment by Jonathan [ 28/Jun/15 ]

8. please do not take offense at all, this is not a personal attack on you at all. This is me, as a novice developer/dba trying to say that the lack of 1 to 1 data type matching in a layer that is supposed to provide a fluid interface results in performance loss.

Thank you for taking the time to read and respond to my reasoning behind my request to be 1st class data mapper for MySQL. I understand the difficulties in trying to be an abstraction layer and convert between all data base engines.
It is just so insane to have to store all of my TinyINT in SmallINT columns just to avoid being confused for a boolean when you run "orm:schema-tool:create" and/or "orm:generate-entities".





[DBAL-1253] Sqlite: inconsistent (non-)support of foreign keys Created: 26/Jun/15  Updated: 26/Jun/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Adirelle Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Tested on Ubuntu 14.10 wth standard PHP packages (5.6 & sqlite 3.8.6) and on Debian Jessie with standard PHP packages (5.6 & sqlite 3.8.6).



 Description   

Though the SqlitePlatform announces it doesn't support foreign keys, it generates foreign key constraints in "alter table" statements.

This leads to issues when combined with Doctrine ORM and/or Doctrine Migrations : the shcema manager doesn't create foreign keys on new tables, but it generates SQL statement to add them on existing tables.

  • Calling the schema update command several times in a row on an existing database causes all tables with relations to be recreated (since Sqlite ALTER TABLE statement is very limited).
  • Even if the database is up to date, using the "diff" command of Doctrine Migrations creates a migration the recreate all tables.

I suggest to disable the declaration of foreign keys at all to avoid these discrepancies.

Background:

  • Before Sqlite 3.6.19, declarations of foreign keys in CREATE TABLE were accepted (and retrieved) but ignored.
  • Starting with 3.6.19, there is a compile option to disable the support of the foreign key syntax in CREATE TABLE statement. There is another compile option to disable the triggers, including foreign key ones. These options can be queried using a PRAGMA statement.
  • Starting with 3.6.19, there is a PRAGMA to enforce the respect of foreign keys.
  • in any case, foreign keys are not supported in ALTER TABLE statements.





Generated at Thu Jul 02 12:35:28 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.