[DC-1062] Testing Created: 08/Jan/14  Updated: 08/Jan/14

Status: Open
Project: Doctrine 1
Component/s: Behaviors
Affects Version/s: 1.2.2
Fix Version/s: 1.2.1

Type: Task Priority: Critical
Reporter: Janardan Singh Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None





[DC-895] [I18n] Defining languages with locality (eg. en_GB) breaks functionality with SQL Integrity error - fix included Created: 20/Oct/10  Updated: 20/Oct/10  Resolved: 20/Oct/10

Status: Resolved
Project: Doctrine 1
Component/s: I18n
Affects Version/s: 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: 1.2.0, 1.2.1, 1.2.2, 1.2.3

Type: Bug Priority: Critical
Reporter: Erik Van Kelst Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None
Environment:

all



 Description   

When defining languages as language_COUNTRY codes (supported by symfony by default), the functionality to work with I18n records breaks, resulting in "SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry" errors.

The reason is very simple: Doctrine's I18n language column is defined as a CHAR(2), thus shortening eg. "en_GB" value to "en", thus causing the above SQL error when a "en" translation for a record already exists.

The solution is even simpler: change the column's length to 7 in the Doctrine_I18n class's options: I've tested this and all runs great: the correct SQL is being generated, the models behave correct, ...



 Comments   
Comment by Erik Van Kelst [ 20/Oct/10 ]

Length of the i18n column is configurable...





[DC-769] Variable type different for return value from Doctrine_Record->toArray() depending on whether the object is from a select, or a save. Created: 27/Jun/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.2.1
Fix Version/s: 1.2.1, 1.2.2

Type: Bug Priority: Major
Reporter: Dennis Gearon Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu9.10, PHP 5.2.6, Symfony 1.4.1, Postgres8.4



 Description   

With a object that is created via a save(), and the record's primary key is a INT fed by a SEQUENCE, the type of the variable is an INT.

With an object that is hydrated from the database via a SELECT, the record's primary key INT will come back in 'toArray()' as a STRING.

That means that checking for type has to know what context it came from, user, INSERT, or SELECT. Not fun.

This also screws up converting arrays to JSON, 'cause the STRINGS get quotation marks and the INTS do not.

As a general rule, everything FROM the database seems to be strings. Yes, I know, everything 'on the wire' or 'through a socket' comes out as text. And it's a lot faster to leave it that way.

But having the type be different depending on the database operation? Not sure I like that.



 Comments   
Comment by Jonathan H. Wage [ 24/Aug/10 ]

Can you provide a test case so that we can see if we can come up with a patch?





[DC-764] Major->please.....Value of Primary key from sequence in Postgres table NOT being set (although sequence gets incremented) Created: 24/Jun/10  Updated: 25/Jun/10  Resolved: 25/Jun/10

Status: Resolved
Project: Doctrine 1
Component/s: Connection, Record
Affects Version/s: 1.2.1
Fix Version/s: 1.2.0, 1.2.1, 1.2.2, 1.2.3

Type: Bug Priority: Major
Reporter: Dennis Gearon Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None
Environment:

Ubuntu9.10 / PHP 5.2.6-3ubuntu4.5 with Suhosin-Patch 0.9.6.2 / Postgres-8.4 / Symfony 1.4.1


Attachments: Zip Archive bugreport.zip     File bug_report_create_postgresql.sql     File schema.yml    

 Description   

In the ERD/schema that I have set up, a couple levels down in hierarchal order, a table has 3 composite foreign keys, and one sequence of its own. That sequence does not get get set into the 'Table->sequence variable'. That means when the file 'UnitOfWork' executes the function '_assignSequence()', it finds no sequence name, and skips the assignment of the sequence value.

This of course blows up my inserts.

I have included the following documentation:

A/ An installation and further description README.tx file.
B/ SQL script to generate a anonymous version of my ERD - I.E. the table names and column names have been changed to protect the guilty (and proprietary)
C/ A fixture file to load some data.
D/ A *.png file showing a graphical view of the ERD.
E/ The generated schema.yml file from ./symfony doctrine:build-schema
F/ A modifiled (has certain echo statements for troubleshooting purposes) UnitOfWork.php file.
G/ A task file to run that tries to load the schema with valid values.
H/ An output file from running the Task and modified UnitOfWork.php file showing the exact point of error during insert.

Please let me know what I can do to help get this troubleshot quicly. Thx
E/



 Comments   
Comment by Dennis Gearon [ 25/Jun/10 ]

Don't know if it's related, but I ran:

./symfony doctrine:build-sql

on the database in this bug report, and none of the tables got sequences assigned to them, nor default values set coming from a sequence.

This is Postgres.

Comment by Dennis Gearon [ 25/Jun/10 ]

So much for getting around this problem easily,

I tried doing this:

$e_table=Doctrine::getTable('E');
$e_table->setOption('sequenceName', 'e_id');
$e_options=$e_table->getOptions();
var_dump($e_options);

before inserting a record into the 'E' table. The option value 'sequenceName' is in the option array and returns correctly. However, when doing an insert immediatley after the above code, I get:

'sequence name was Array' (from my troubleshooting 'echo' statements in the modified UnitOfWork.php file)

and the following errors: (you have to be using my modified UOW.php file to get the same line number there.)

Warning: Illegal offset type in /home/bugreport/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Connection/UnitOfWork.php on line 917

Warning: Illegal offset type in /home/bugreport/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Record.php on line 2222

Warning: Illegal offset type in /home/bugreport/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Record.php on line 2223
PREVIOUS line was processingSingleInsert

Warning: Invalid argument supplied for foreach() in /home/bugreport/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Record.php on line 1151

So I am wondering, does the public function table->setOption(); even work, correclty that is?

Comment by Dennis Gearon [ 25/Jun/10 ]

If I instead just retrieve the next val of the sequence manually, change 'id' column manually, then it works. But It then fails on the insert into the 'J' table.

Apparently, Doctrine does not like composite primary foreign keys with a sequence also part of the foreign key. I wonder if my file would work on the Oracle version?

Comment by Dennis Gearon [ 25/Jun/10 ]

Showing simpler version of ERD/Schema converting Primary Foreign Keys to Foreign keys. The then required unique index on the former Primary Foreign Keys has not yet been coded. Just create it on all the keys in tables E and J, that were listed as primary in the first version in the zip file

Comment by Dennis Gearon [ 25/Jun/10 ]

See last comment, but the short answer is . . . at this date, 2010-06-25, even Doctrine 2.0-DBAL can't do what I'm trying to get verson 1.2.1 to do.

So I got around it by converting primary foreign keys to foreign keys and then putting a unique index on the formerly primary keys.

However, the child of the table treated that way, E(parent), J(child), now only has one foreign key, for E. To get all the ancestors, I will have to do subselects and joins. Oh well.





[DC-674] NULL Dates are translated to '0000-00-00' after upgrading to 1.2.2 Created: 10/May/10  Updated: 06/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Behaviors
Affects Version/s: 1.2.1, 1.2.2
Fix Version/s: 1.2.1, 1.2.2

Type: Bug Priority: Critical
Reporter: Ville Itämaa Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Zend Framework, Ubuntu 9.10, MySQL



 Description   

Once the upgrade was done from Doctrine 1.2.1 to 1.2.2 we discovered that date related issues started to appear.
With dates that are persisted in DB as NULL are translated to "0000-00-00" when retrieved from DB. This has occurred in multiple places and is quite worrying as there is a lot of dates in our project. This means that everywhere in our codebase where we check a datevalue in our Models is NULL we need also to check for the string literal "0000-00-00".



 Comments   
Comment by Jonathan H. Wage [ 10/May/10 ]

Are you able to reproduce this in a test case?

Comment by Ville Itämaa [ 11/May/10 ]

We reverted to Doctrine 1.2.1 after realising the bug to confirm it was Doctrine 1.2.2 that was the cause for the problem. And as a result the records with NULL dates in the DB became NULL in the Models.
But when using Doctrine 1.2.2, the NULL dates became '0000-00-00' in the Models.
I don't have any other way to reproduce this error.

Comment by Jonathan H. Wage [ 11/May/10 ]

Were you able to identity which changeset it was? You can read about creating test cases here http://www.doctrine-project.org/documentation/manual/1_2/en/unit-testing

So far I am not able to reproduce the error you described.

Comment by Jonathan H. Wage [ 08/Jun/10 ]

I'd like to fix this. Did you ever figure out which changeset introduced the issue? I've been trying to figure it out myself.

Comment by Roland Huszti [ 06/Oct/10 ]

With 1.2.3 this works for me fine with both TIMESTAMP and DATE fields.

YAML

        date_of_birth:
            type: date

BASE MODEL

        $this->hasColumn('date_of_birth', 'date', null, array(
             'type' => 'date',

             // try these two
             // 'notnull' => false,
             // 'default' => null
         ));
YAML

        exported_at:
            type: timestamp(25)
            notnull: false
            default: null

            # in this model I have everything to make sure it accepts and defaults to NULL

BASE MODEL

        $this->hasColumn('exported_at', 'timestamp', 25, array(
             'type' => 'timestamp',
             'notnull' => false,
             'length' => '25',
             ));

You may try adding these to your YAML and (base) models

YAML

    fieldname:
         . . .
        notnull: false
        default: null

BASE MODEL

        $this->hasColumn('fieldname', . . .
             . . .
             'notnull' => false, // <<<<<<<
             // 'default' => null, // <<< maybe, probably not needed
             ));

I hope it helps.





[DC-580] if deleting root with Doctrine_Node_NestedSet::delete() deletes all root nodes Created: 17/Mar/10  Updated: 17/Mar/10  Resolved: 17/Mar/10

Status: Resolved
Project: Doctrine 1
Component/s: Nested Set
Affects Version/s: 1.2.1
Fix Version/s: 1.2.1

Type: Improvement Priority: Major
Reporter: Michael Assignee: Roman S. Borschel
Resolution: Fixed Votes: 0
Labels: None


 Description   

Im using next code
$category = Doctrine_Core::getTable('Mr_DirectoryTreeNodes')->findOneBy('id',$params['id']);
$node = $category->getNode();
$node->delete();

Doctrine_Node_NestedSet::delete() deletes all root nodes;
_____________________

to fix add

$q = $q->addWhere("$baseAlias.id = ?", $this->record->get('id'));

after :

$q = $q->addWhere("$baseAlias.lft >= ? AND $baseAlias.rgt <= ?", array($this->getLeftValue(), $this->getRightValue()));



 Comments   
Comment by Michael [ 17/Mar/10 ]

with

public function setUp()

{ $options = array( 'hasManyRoots' => true, 'rootColumnName' => 'root_id' ); $this->actAs('Timestampable'); $this->actAs('NestedSet',$options); parent::setUp(); }

);

it works propertly





[DC-553] issue when changing the connection inside Doctrine_Query::preQuery() on a model using a behavior Created: 08/Mar/10  Updated: 19/Jul/10

Status: Open
Project: Doctrine 1
Component/s: Behaviors
Affects Version/s: None
Fix Version/s: 1.2.1

Type: Bug Priority: Major
Reporter: Lukas Kahwe Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We were following:
http://www.doctrine-project.org/documentation/cookbook/1_1/en/master-and-slave-connections

class MyQuery extends Doctrine_Query
{
// Since php doesn't support late static binding in 5.2 we need to override
// this method to instantiate a new MyQuery instead of Doctrine_Query
public static function create($conn = null)

{ return new MyQuery($conn); }

public function preQuery()
{
// If this is a select query then set connection to one of the slaves
if ($this->getType() == Doctrine_Query::SELECT)

{ $this->_conn = Doctrine_Manager::getInstance()->getConnection('slave_' . rand(1, 4)); // All other queries are writes so they need to go to the master }

else

{ $this->_conn = Doctrine_Manager::getInstance()->getConnection('master'); }

}
}

However we are actually forcing all queries after the first access to the master to be run against the master (including selects). Note the example should probably be changed to use setConnection(). However even when using setConnection() it seems like changing the connection can cause issues when running a select on a model with a behavior (in our case we were using i18n). Therefore we believe there is some issue that is caused through the event system, because otherwise queries work just fine even when changing the connection as per the above described code.

We managed to fix things, by not setting the connection explicitly and instead simply using setCurrentConnection('master'), so the bug does not affect us anymore. However this seems to indicate some issues deep inside the event-behavior-template code.



 Comments   
Comment by Jordi Boggiano [ 08/Mar/10 ]

In case the above post is confusing, note that doing $this->_conn = masterconn worked fine for the INSERT, it just broke when doing a subsequent SELECT of a translateable (I18n behavior) model and its Translation table with the following exception:

Exception (Exception): Unknown relation alias Translation (#0)</h1>thrown in file /Library/WebServer/Documents/liip/infocube/ext/db-doctrine/lib/Doctrine/Relation/Parser.php at line 237
backtrace:
#1 Doctrine_Relation_Parser->getRelation called in file /Library/WebServer/Documents/liip/infocube/ext/db-doctrine/lib/Doctrine/Relation/Parser.php at line 235

Comment by Jonathan H. Wage [ 15/Mar/10 ]

It is hard to understand the issue, can you provide a test case?

Comment by Lukas Kahwe [ 15/Mar/10 ]

We already spend well over 2 hours together on project time to find a work around as noted above and I must admit now our motivation is not so big to dig deeper, especially since we didn't find the cause in this time and have the feeling its pretty impossible to fix without huge risks.

Essentially I think all you need to do to reproduce the issue is use the cookbook code and issue some write query and afterwards do a select on a model that has the translatable behavior. It then gave us the above Exception.

Our code worked slightly different since we did not use a random slave, instead we always used a local slave by default, but the first write and any queries thereafter would get send to the master. The code is public and the diff's show what we had to change to get things working. Note that the slave "localhost" connection was the default connection:
http://fisheye.liip.ch/browse/PUB/okapi2/ext/db-doctrine/trunk/inc/DQ.php?r1=13118&r2=
http://fisheye.liip.ch/browse/PUB/okapi2/ext/db-doctrine/trunk/inc/DR.php?r1=13118&r2=

Comment by Lukas Kahwe [ 17/Jun/10 ]

we thought we had the issue fixed but ran into another issue today. we then noticed that the issue goes away if we just copy the $tables property from the old connection to the new connection. there is a getTables() method, but there is only a addTable() method, would be nice to have a addTables() method that is faster. or maybe a switchFrom() method that accepts the old connection and does whatever it needs to.

And again it would be nice to update the cookbook entry.
Here are our updated Doctrine_Query and Doctrine_Record classes:
http://fisheye.liip.ch/browse/PUB/okapi2/ext/db-doctrine/trunk/inc/DQ.php
http://fisheye.liip.ch/browse/PUB/okapi2/ext/db-doctrine/trunk/inc/DR.php

Comment by Jordi Boggiano [ 19/Jul/10 ]

We just had another funny debugging session related to this. It turns out that the Table objects have a relation to the connection, and if you query a new model that wasn't initialized yet using ->from(), it works because it just gets the current connection passed. However, if you query a new model within a JOIN, then it apparently takes the connection from the related model you're joining from. In our case, the related model was already initialized but had an instance of the old (slave) connection, and so the new model was initialized using the wrong connection, and then the DQL parser exploded trying to resolve relations.

Long story short, adding $table->setConnection($conn); to all tables while switching to the master connection resolved it. The code is updated and you can still view it at the above URLs, or straight in the SVN repo at http://svn.liip.ch/repos/public/okapi2/ext/db-doctrine/trunk/inc/DQ.php





[DC-528] CLONE -isValueModified returns true for timestamps that appear different but are equal Created: 26/Feb/10  Updated: 02/Mar/10  Resolved: 02/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Validators
Affects Version/s: 1.2.1
Fix Version/s: 1.2.1

Type: Bug Priority: Major
Reporter: Florian Klucke Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: File DC57TestCase.diff    

 Description   

This is a copy of DC57:

"Doctrine_Record::isValueModified compares timestamps as strings and values that are equal such as 2009-09-02 00:00:00 and 2009-09-02 are treated as modified.

The code should do a second compare on the strtotime value if the strings appear to be unequal."

The changes made with this ticket causes problems with old timestamps because of strtotimes behaviour with dates before beginning of unix-period. I attached a diff for the original testcase to demonstrate the problem.






[DC-333] Doctrine_Migration_Diff reuses the same temporary folder on consecutive runs, resulting in collisions between projects Created: 07/Dec/09  Updated: 07/Dec/09  Resolved: 07/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Critical
Reporter: Tom Boutell Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Symfony 1.3 with MacPorts PHP 5.3.1



 Description   

svn co http://svn.symfony-project.com/plugins/pkContextCMSPlugin/sandbox/branches/1.3 cmstest13
cd cmstest13
[edited config/doctrine/schema.yml and added a trivial table so there would be something at the app level]
[successful doctrine:build --all followed]

./symfony doctrine:generate-migrations-diff
>> doctrine generating migration diff
>> file+ /private/var/folders/3H/3Hu3TTyjFt...TI/Tmp/doctrine_schema_15549.yml

Fatal error: Class 'EventUser' not found in /private/var/folders/3H/3Hu3TTyjFtuvtN3D5tDUxU+++TI/Tmp/fromprfx_doctrine_tmp_dirs/base/BaseEventGuest.class.php on line 7

I recognize my personal temp folder from my environment in there:

TMPDIR=/var/folders/3H/3Hu3TTyjFtuvtN3D5tDUxU+++TI/Tmp/

So presumably these tasks are supposed to clean it up after they use it. But none of my attempts to use this task so far have succeeded, so I suspect the problem is that the folder does not get cleaned up in the event of an error. This folder needs to get cleaned up on all errors, or perhaps cleared at the start of a new run (that is probably going to turn out to be a more reliable fix).

I'll manually clear it and move on to the bug I was originally looking to reproduce.



 Comments   
Comment by Jonathan H. Wage [ 07/Dec/09 ]

Hmm. When I look at Doctrine_Migration_Diff we implement a _cleanup() method that is for that purpose. Does it not clean up the directory properly?

Comment by Tom Boutell [ 07/Dec/09 ]

[Peeks at source]

Looks like you do it last. If an exception is thrown it doesn't happen (I just verified that I have a full folder of classes left behind after an attempt to use it). Then you have a lingering problem confounding your attempts to try again.

Suggest you call _cleanup() at the start and the end. The first call won't take much time at all if the last run was a happy one. If it was an unhappy one you really need it.

  • * *

A much more minor issue:

I'm a little nervous about the fact that if I were running two schema diffs for two different projects at once, they would still collide, sharing the same tmp folder. I would suggest starting everything from TMP/doctrine-$pid where $pid = getpid() or something like that.

In pkToolkit we use SF_ROOT_DIR/data/pk_writable/tmp because that is safely project-specific.

Comment by Jonathan H. Wage [ 07/Dec/09 ]

Tom, as you have an environment setup with the problem exposed, could you prepare a patch that fixes the problems you are encountering?

Comment by Jonathan H. Wage [ 07/Dec/09 ]

So I just want to confirm. We have two issues now. The _cleanup() method needs to be called when it starts. This patch should take care of that:

Index: lib/Doctrine/Migration/Diff.php
===================================================================
--- lib/Doctrine/Migration/Diff.php	(revision 6882)
+++ lib/Doctrine/Migration/Diff.php	(working copy)
@@ -93,6 +93,8 @@
      */
     public function generateChanges()
     {
+        $this->_cleanup();
+
         $from = $this->_generateModels(self::$_fromPrefix, $this->_from);
         $to = $this->_generateModels(self::$_toPrefix, $this->_to);

Now we have another issue where the paths could conflict. Can we open another ticket to work on that issue? Can you confirm that the above patch fixes this individual issue?

Comment by Tom Boutell [ 07/Dec/09 ]

Yes that is the correct patch, I just prepared the exact same patch and went back to my email to find the ticket and saw your comment.

I will open a separate ticket re: the potential clash between projects. It's certainly less probable but it doesn't make sense for them to contend for a single folder.

Thanks!

Comment by Jonathan H. Wage [ 07/Dec/09 ]

Cool. Yes I think we can fix the other issue but in another revision/ticket. I will go ahead and commit that patch and close this ticket.

Thanks, Jon





[DC-330] Doctrine_Table unshiftFilter() expects method Doctrine_Record_Filter init() Created: 05/Dec/09  Updated: 07/Dec/09  Resolved: 07/Dec/09

Status: Resolved
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Trivial
Reporter: Jonathan Collins Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows, PHP 5.2.9-2


Attachments: Text File DC-330-Doctrine_Record_Filter.patch    

 Description   

That method is not defined in Doctrine_Record_Filter either as abstract or with empty implementation, only in Doctrine_Record_Filter_Compound.

Doctrine_Record_Filter_Standard seems to get around this by not being registered via unshiftFilter()






[DC-317] Using NestedSet behavior, createRoot function doesn't behave as expected with string multiple root key Created: 03/Dec/09  Updated: 07/Dec/09  Resolved: 07/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: Behaviors, Nested Set
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Major
Reporter: Julien G Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Using Symfony 1.4 and MySQL



 Description   

I have defined this model :

 
Page:
  options: { type: InnoDB, collate: utf8_unicode_ci, charset: utf8 }
  columns:
    topic:       { type: string(32), notnull: true }
    title:        { type: string(255), notnull: true }
  actAs:
    NestedSet:      { hasManyRoots: true, rootColumnName: topic }

And use this code (database is empty) :

<?

$page = new Page;
$page->topic = 'my-topic';
$page->title = 'My Title';
$page->save();

print_r( $page->topic );  // OK, here it's perfect

Doctrine::getTable('Page')->getTree()->createRoot( $page );

print_r( $page->topic ); // Now topic == 1 . It's buggy !


Doctrine::getTable('Page')->getTree()->fetchTree( 'my-topic' ); // Buggy : return false !

?>

Let me know if you need more explainations,
julien






[DC-314] length option ignored in addColumn method in Doctrine 1.2 migrations Created: 02/Dec/09  Updated: 02/Dec/09  Resolved: 02/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Major
Reporter: Tom Boutell Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Symfony 1.3



 Description   

I am using http://doctrine.mirror.svn.symfony-project.com/branches/1.2/lib and saw this problem with revision 6806.

The 'length' parameter in the options array seems to be
ignored by addColumn in Doctrine 1.2 migrations. No matter what we specified for
'length' we got a bigint in MySQL, resulting in failure later when we
tried to add a foreign key because we needed a 4-byte integer. There
does not seem to be any documentation of what is valid in the options
array when calling addColumn, however I see that length is still used
when passing an apparently identical options array for a particular
column when calling createTable.

That is, this code:

$this->addColumn('pg_event_request', 'event_id', 'integer',
array('length' => 4));

Does not work properly in Doctrine 1.2 (you get a bigint in MySQL).

We were able to work around it by implementing a migrate() method
instead, passing 4 as the final argument (there doesn't seem to be
clear documentation of this final argument but in the example in the
documentation it is the length of a string column, and sure enough it
does the same thing for an integer). Passing 4 here worked, we got a
4-byte integer.



 Comments   
Comment by Jonathan H. Wage [ 02/Dec/09 ]

I just fixed this here hehe

http://trac.doctrine-project.org/changeset/6842

Also, the function signature in 1.2 is:

    public function addColumn($tableName, $columnName, $type, $length = null, array $options = array())

It has the $length argument, but you can still pass the length via the options. In the end all that information is just in one array.





[DC-308] Doctrine is throwing base and not project-level Exceptions Created: 01/Dec/09  Updated: 01/Dec/09  Resolved: 01/Dec/09

Status: Resolved
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Improvement Priority: Trivial
Reporter: Juozas Kaziukenas Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: Text File doctrine.patch     Text File sfyaml.patch    

 Description   

Files (without locations, easy to find):

Doctrine_Adapter_Statement_Oracle
replace to Doctrine_Adapter_Exception

Doctrine_Node_NestedSet
replace to Doctrine_Node_Exception

sfYamlInline from Doctrine\Parser\sfYaml
replace with InvalidArgumentException



 Comments   
Comment by Jonathan H. Wage [ 01/Dec/09 ]

It would be much easier with patches

Comment by Juozas Kaziukenas [ 01/Dec/09 ]

One second

Comment by Jonathan H. Wage [ 01/Dec/09 ]

Actually, do you have a trac account? I can give you SVN access and you can commit the changes yourself. But, you must create tickets before committing anything and get approval from someone before committing. Allowing you to commit directly will just ease the process a little.

Comment by Juozas Kaziukenas [ 01/Dec/09 ]

Attached patches (sfYaml is separate, Tortoise refused to do otherwise)

I don't have trac account, but I'm interested in contributing more since I work with Doctrine day and night

Comment by Jonathan H. Wage [ 01/Dec/09 ]

I sent you an e-mail about SVN access.





[DC-307] Oracle adapter statement is not behavin correctly when error mode is Doctrine_Core::ERRMODE_SILENT or Doctrine_Core::ERRMODE_WARNING Created: 01/Dec/09  Updated: 01/Dec/09  Resolved: 01/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Minor
Reporter: Juozas Kaziukenas Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

Fetch column method looks like this:

public function fetchColumn($columnIndex = 0)
{
if ( ! is_integer($columnIndex)) {
$this->handleError(array('message'=>"columnIndex parameter should be numeric"));
}
$row = $this->fetch(Doctrine_Core::FETCH_NUM);
return $row[$columnIndex];
}

Method handleError() not always throws an exception, and by passing it a string or any other variable type than integer will result in warning.

Fix (depending on what is considered to be required by interface):

if ( ! is_integer($columnIndex)) {
$this->handleError(array('message'=>"columnIndex parameter should be numeric"));
return false;
}

or

if ( ! is_integer($columnIndex)) {
throw new Doctrine_Adapter_Exception("columnIndex parameter should be numeric");
}



 Comments   
Comment by Juozas Kaziukenas [ 01/Dec/09 ]

Fixed code comments

Comment by Jonathan H. Wage [ 01/Dec/09 ]

I don't quite understand what you are wanting me to change here. can you explain?

Comment by Jonathan H. Wage [ 01/Dec/09 ]

Nevermind, I understand. I think returning false is probably the right choice, don';t you think?

Comment by Juozas Kaziukenas [ 01/Dec/09 ]

If I pass:

fetchColumn('test')

and the error level is set like above, this code will generate php notice, because you will be trying:

return $row['test'];

So the problem is - when handleError() is not throwing exception, check is_integer() is almost ignored.

Comment by Juozas Kaziukenas [ 01/Dec/09 ]

I would say false is correct. Although it depends on what interface is expecting.

I don't know about Oracle, but some RDBMS support boolean types and false can be a value too, so when you are returning false here, in user code it would be hard to detect a problem. (although it's hardly plausible)





[DC-306] Oracle adapter statement is referencing non-existing constants Created: 01/Dec/09  Updated: 01/Dec/09  Resolved: 01/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Trivial
Reporter: Juozas Kaziukenas Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

Line 316 in Doctrine/Adatper/Statement/Oracle.php has:

case FETCH_OBJ:
return oci_fetch_object($this->statement, OCI_NUM + OCI_RETURN_NULLS + OCI_RETURN_LOBS);
break;

There is no constant FETCH_OBJ, so line should be:

case Doctrine_Core::FETCH_OBJ:
return oci_fetch_object($this->statement, OCI_NUM + OCI_RETURN_NULLS + OCI_RETURN_LOBS);
break;






[DC-305] Oracle adapter statement closeCursor() is not working properly Created: 01/Dec/09  Updated: 01/Dec/09  Resolved: 01/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: Connection
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Major
Reporter: Juozas Kaziukenas Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

Close cursor method cleans up non-existing array $bind_params, correct variable name is $bindParams. (comment of $bindParams is wrong to because it also speaks about $bind_params)

Now:

public function closeCursor()
{
$this->bind_params = array();
return oci_free_statement($this->statement);
}

Fix:

public function closeCursor()
{
$this->bindParams = array();
return oci_free_statement($this->statement);
}






[DC-304] Auloader returns false even though sfYaml* class is loaded Created: 01/Dec/09  Updated: 01/Dec/09  Resolved: 01/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Minor
Reporter: Juozas Kaziukenas Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

Autoloader loads method has lines:

if (0 !== stripos($className, 'Doctrine_') || class_exists($className, false) || interface_exists($className, false)) {
return false;
}

Which for sfYaml classes always are true (0 !== stripos('sfYaml', 'Doctrine_') ==> true) and hence autoloader returns false. This creates problems if there are more than one autoloader in the stack.

Fix:

{qupte}

if (strpos($className, 'sfYaml') === 0)

{ require dirname(__FILE__) . '/Parser/sfYaml/' . $className . '.php'; return true; } {quote}




[DC-302] Issues when using automatic relations ordering through 'orderBy' param in m2m relations Created: 01/Dec/09  Updated: 01/Dec/09  Resolved: 01/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: Record, Relations
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Major
Reporter: Maciej Hołyszko Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 2
Labels: None
Environment:

php 5.3/win, doctrine 1.2 svn, ATTR_QUOTE_IDENTIFIER = true, ATTR_USE_DQL_CALLBACKS = true


Attachments: File DC302TestCase.php    

 Description   

Partially related to DC-240.

I found some additional problems, mainly with self-referenced relations.
I use ACL system with multiple inheritance, where order of inherited elements matters.
Here we have (Role <- m2m orderBy position - > Role) and (User < - m2m orderBy position -> Role):

class Role extends Doctrine_Record
{
	public function setTableDefinition()
	{
		$this->hasColumn('name', 'string', 64);
	}
	
	public function setUp()
	{
		$this->hasMany('User as Users', array('local' => 'id_role', 'foreign' => 'id_user', 'refClass' => 'UserRole'));
		$this->hasMany('Role as Parents', array('local' => 'id_role_child', 'foreign' => 'id_role_parent', 'refClass' => 'RoleReference', 'orderBy' => 'position'));
		$this->hasMany('Role as Children', array('local' => 'id_role_parent', 'foreign' => 'id_role_child', 'refClass' => 'RoleReference'));
	}
}

class RoleReference extends Doctrine_Record
{
	public function setTableDefinition()
	{
		$this->hasColumn('id_role_parent', 'integer', null, array('primary' => true));
		$this->hasColumn('id_role_child', 'integer', null, array('primary' => true));
		$this->hasColumn('position', 'integer', null, array('notnull' => true));
	}
	
	public function setUp()
	{
		$this->hasOne('Role as Parent', array('local' => 'id_role_parent', 'foreign' => 'id', 'onDelete' => 'CASCADE'));
		$this->hasOne('Role as Child', array('local' => 'id_role_child', 'foreign' => 'id', 'onDelete' => 'CASCADE'));
	}
}

class User extends Doctrine_Record
{
	public function setTableDefinition()
	{
		$this->hasColumn('username', 'string', 64, array('notnull' => true));
		$this->hasColumn('password', 'string', 128, array('notnull' => true));
	}
	
	public function setUp()
	{
		$this->hasMany('Role as Roles', array('local' => 'id_user', 'foreign' => 'id_role', 'refClass' => 'UserRole', 'orderBy' => 'position'));
	}
}

class UserRole extends Doctrine_Record
{
	public function setTableDefinition()
	{
		$this->hasColumn('id_user', 'integer', null, array('primary' => true));
		$this->hasColumn('id_role', 'integer', null, array('primary' => true));
		$this->hasColumn('position', 'integer', null, array('notnull' => true));
	}
	
	public function setUp()
	{
		$this->hasOne('User', array('local' => 'id_user', 'foreign' => 'id', 'onDelete' => 'CASCADE'));
		$this->hasOne('Role', array('local' => 'id_role', 'foreign' => 'id', 'onDelete' => 'CASCADE'));
	}
}

Sample data:

$role1 = new Role();
$role1->name = 'admin'; // id: 1
$role1->save();

$role2 = new Role();
$role2->name = 'publisher'; // id: 2
$role2->save();

$role3 = new Role();
$role3->name = 'reviewer'; // id: 3
$role3->save();

$role4 = new Role();
$role4->name = 'mod'; // id: 4
$role4->save();

// reviewer inherits from admin, mod, publisher - in that order
$role3->Parents[] = $role1;
$role3->Parents[] = $role4;
$role3->Parents[] = $role2;
$role3->save();

// update positions
$query = Doctrine_Query::create()
	->update('RoleReference')
	->set('position', '?', 0)
	->where('id_role_child = ?', 3)
	->andWhere('id_role_parent = ?', 1)
	->execute();
$query = Doctrine_Query::create()
	->update('RoleReference')
	->set('position', '?', 1)
	->where('id_role_child = ?', 3)
	->andWhere('id_role_parent = ?', 4)
	->execute();
$query = Doctrine_Query::create()
	->update('RoleReference')
	->set('position', '?', 2)
	->where('id_role_child = ?', 3)
	->andWhere('id_role_parent = ?', 2)
	->execute();
	

// add test user
$user = new User();
$user->username = 'test';
$user->password = 'test';
$user->fromArray(array('Roles' => array(4, 2)));
$user->save();
// update positions
$query = Doctrine_Query::create()
	->update('UserRole')
	->set('position', '?', 0)
	->where('id_user = ?', 1)
	->andWhere('id_role = ?', 4)
	->execute();
$query = Doctrine_Query::create()
	->update('UserRole')
	->set('position', '?', 1)
	->where('id_user = ?', 1)
	->andWhere('id_role = ?', 2)
	->execute();

Now, lazy-loading self-referenced m2m relations seems to be the issue (I know lazy-loading is wrong but it's needed to be like that in some parts of our system):

$role = Doctrine::getTable('Role')->find(3);
print_r($role->Parents->toArray());

The query which is created and executed during lazy-load of Parents relations is as follows:

SELECT role.id AS role__id, role.name AS role__name, role_reference.id_role_parent AS role_reference__id_role_parent, role_reference.id_role_child AS role_reference__id_role_child, role_reference.position AS role_reference__position FROM role INNER JOIN role_reference ON role.id = role_reference.id_role_parent WHERE role.id IN (SELECT id_role_parent FROM role_reference WHERE id_role_child = ?) ORDER BY role.id ASC, position

(seems a little strange as there are no automatically generated aliases e.g. r1, r2 etc. but whole table names)
The result is ordered by role.id first, then by position (without any alias and that could be an additional problem in some cases)

The result is: (as you can see the order of roles is 1, 2, 4 (positions: 0, 2, 1) instead of 1, 4, 2)

Array
(
    [0] => Array
        (
            [id] => 1
            [name] => admin
            [RoleReference] => Array
                (
                    [0] => Array
                        (
                            [id_role_parent] => 1
                            [id_role_child] => 3
                            [position] => 0
                            [Parent] => 
                        )

                )

        )

    [1] => Array
        (
            [id] => 2
            [name] => publisher
            [RoleReference] => Array
                (
                    [0] => Array
                        (
                            [id_role_parent] => 2
                            [id_role_child] => 3
                            [position] => 2
                            [Parent] => 
                        )

                )

        )

    [2] => Array
        (
            [id] => 4
            [name] => mod
            [RoleReference] => Array
                (
                    [0] => Array
                        (
                            [id_role_parent] => 4
                            [id_role_child] => 3
                            [position] => 1
                            [Parent] => 
                        )

                )

        )

)

It is NOT an issue with lazy-loading m2m relations between two different models:

$user = Doctrine::getTable('User')->find(1);
print_r($user->Roles->toArray());

The query generated seems to be correct: (well except the lack of an alias in front of position column in ORDER BY clause)

SELECT `r`.`id` AS `r__id`, `r`.`name` AS `r__name`, `u`.`id_user` AS `u__id_user`, `u`.`id_role` AS `u__id_role`, `u`.`position` AS `u__position` FROM `role` `r` LEFT JOIN `user_role` `u` ON `r`.`id` = `u`.`id_role` WHERE (`u`.`id_user` IN (?)) ORDER BY position

It works well for self-referenced relations where relation are defined in DQL e.g.:

$query = Doctrine_Query::create()
	->from('Role r')
	->leftJoin('r.Parents rp')
	->orderBy('r.name ASC')
	->where('r.id = ?', 3);
	
var_dump($query->getSqlQuery());
$result = $query->fetchOne();

print_r($result->Parents->toArray());

To sum up:
1. orderBy in m2m self-referenced relations does not work when they are lazy-loaded
2. lack of table alias for orderBy column when lazy-loading m2m relations between separate models (possibly not an issue?)

I am not sure if the first one could be fixed at all, due to specific query construction? If not, I would be glad to see a possible workaround for this problem.

Thanks in advance.



 Comments   
Comment by Maciej Hołyszko [ 01/Dec/09 ]

Attached test case. I did not know how to test the second issue - is there a db profiler available during unit testing?

Comment by Jonathan H. Wage [ 01/Dec/09 ]

Thanks for the report and test case. I made a change and your test case passes now.





[DC-298] Doctrine_Cache_Driver : array_search() expects parameter 2 to be array, boolean given at line 283 Created: 27/Nov/09  Updated: 01/Dec/09  Resolved: 01/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: Caching
Affects Version/s: 1.2.0-RC1
Fix Version/s: 1.2.1

Type: Bug Priority: Major
Reporter: Benoît Guchet Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: File Doctrine_Cache_Array.doDelete.new    

 Description   

Doctrine_Cache_Driver::fetch() is supposed to return a string, but an array_search() is made on it by Doctrine_Cache_Driver::_deleteKey() (at line 283).



 Comments   
Comment by Jonathan H. Wage [ 30/Nov/09 ]

I don't quite understand. Can you explain more?

Comment by Jonathan H. Wage [ 30/Nov/09 ]

Reading your description it doesn't make any sense. Re-open if you have a better more clear description of the problem.

Comment by Benoît Guchet [ 30/Nov/09 ]

It's not very complicated :

In Doctrine_Cache_Driver::_deleteKey, you do array_search() with the array $keys as haystack:

$keys = $this->fetch($this->_cacheKeyIndexKey);
$key = array_search($key, $keys);

But $keys is a string, because Doctrine_Cache_Driver::fetch returns a string (or false) :

/**

  • Fetch a cache record from this cache driver instance
    *
  • @param string $id cache id
  • @param boolean $testCacheValidity if set to false, the cache validity won't be tested
  • @return string cached datas (or false)
    */
    public function fetch($id, $testCacheValidity = true)

You can't make an array_search on a string.

I can't be more clear

edit : You may tell me that the PHPdoc is wrong : but the problem still appears when ::fetch returns false.

Comment by Jonathan H. Wage [ 30/Nov/09 ]

The api documentation is wrong, fetch always returns the data structure that was originally stored. So in this case it is an array.

Comment by Benoît Guchet [ 30/Nov/09 ]

Ok i've anticipated this answer

So Cf. edit of my last comment.

Comment by Jonathan H. Wage [ 30/Nov/09 ]

I updated the API doc blocks.

Comment by Benoît Guchet [ 01/Dec/09 ]

Sorry, I reopen this issue again because I still encounter it.

I've watched it deeper to make it reproductible :

I'm using Doctrine_Cache_Array.
The problem simply appears when you try to delete a cache entry that does not exist.

example :

$cache = new Doctrine_Cache_Array();
$cache->delete(45);

Comment by Benoît Guchet [ 01/Dec/09 ]

Patch to Doctrine_Cache_Array::_doDelete() so that it returns false if the entry does not exist.





[DC-126] Doctrine_Migration_Diff breaks on inherited class Created: 20/Oct/09  Updated: 29/Mar/10  Resolved: 07/Dec/09

Status: Closed
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.0-ALPHA1, 1.2.0-ALPHA2
Fix Version/s: 1.2.1

Type: Bug Priority: Major
Reporter: Marc Weistroff Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

php 5.3 / symfony 1.3



 Description   

This ticket is a duplicate of this one http://trac.symfony-project.org/ticket/7272 but it's more a Doctrine bug than a symfony one.

When trying to make a diff on schema with inheritance, the task breaks when trying to load a model inherited from an other one. I think this is because the inherited model might be loaded before his ancestor.



 Comments   
Comment by Jonathan H. Wage [ 20/Oct/09 ]

test case? any code to duplicate?

Comment by Marc Weistroff [ 20/Oct/09 ]

First a patch which is more a proof of concept...
It's getting late here and will code the test case tomorrow

Comment by Marc Weistroff [ 21/Oct/09 ]

I'm having difficulties to prove it with the Doctrine Sandbox... Because it works fine in this case... :'(
I past the error log, it might be helpful:

stlto28:www marc$ php symfony doctrine:generate-migrations-diff
>> doctrine  generating migration diff
>> file+     /private/var/folders/vu/vuQEAsRN...-Tmp-/doctrine_schema_IRajfY.yml
PHP Fatal error:  Class 'ToPrfxuvmcCmsContent' not found in /private/var/folders/vu/vuQEAsRNGECmKgHPU7Y1vk+++TI/-Tmp-/toprfx_doctrine_tmp_dirs/ToPrfxuvmcCmsArticle.php on line 15
PHP Stack trace:
PHP   1. {main}() /myProject/symfony:0
PHP   2. include() /myProject/symfony:14
PHP   3. sfSymfonyCommandApplication->run() /myProject/lib/vendor/symfony/lib/command/cli.php:20
PHP   4. sfTask->runFromCLI() /myProject/lib/vendor/symfony/lib/command/sfSymfonyCommandApplication.class.php:76
PHP   5. sfBaseTask->doRun() /myProject/lib/vendor/symfony/lib/task/sfTask.class.php:97
PHP   6. sfDoctrineGenerateMigrationsDiffTask->execute() /myProject/lib/vendor/symfony/lib/task/sfBaseTask.class.php:67
PHP   7. sfDoctrineBaseTask->callDoctrineCli() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/task/sfDoctrineGenerateMigrationsDiffTask.class.php:65
PHP   8. Doctrine_Cli->run() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/task/sfDoctrineBaseTask.class.php:64
PHP   9. Doctrine_Cli->_run() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Cli.php:148
PHP  10. Doctrine_Task_GenerateMigrationsDiff->execute() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Cli.php:210
PHP  11. Doctrine_Migration_Diff->generateMigrationClasses() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Task/GenerateMigrationsDiff.php:48
PHP  12. Doctrine_Migration_Builder->generateMigrationsFromDiff() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Diff.php:111
PHP  13. Doctrine_Migration_Diff->generateChanges() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Builder.php:147
PHP  14. Doctrine_Migration_Diff->_diff() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Diff.php:99
PHP  15. Doctrine_Core::loadModels() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Diff.php:125
PHP  16. require_once() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Core.php:649
Comment by Marc Weistroff [ 21/Oct/09 ]

I tryed to reproduce the failing case in a doctrine sandbox but the task is executed just fine... So I tried with a Symfony sandbox and it failed.
I guess there is some kind of autoloading incompatibility somewhere.

I uploaded a sandbox on symfony's trac with the failing schema. The ticket is viewable here http://trac.symfony-project.org/ticket/7272

Thanx

Comment by Jonathan H. Wage [ 18/Nov/09 ]

This issue cannot be reproduced and no new information has been given.

Comment by Alex Gilbert [ 02/Dec/09 ]

I am having this problem as well.


>> doctrine generating migration diff
>> file+ /private/var/folders/uO/uOcfxzTRGA8G6XQvExbGF++++TI/Tmp/doctrine_schema_87129.yml

Fatal error: Class 'ToPrfxpkContextCMSSlot' not found in /private/var/folders/uO/uOcfxzTRGA8G6XQvExbGF++++TI/Tmp/toprfx_doctrine_tmp_dirs/ToPrfxpkContextCMSButtonSlot.php on line 14

{/code}

The most recent activity on this issue seems to be in the symfony Trac, where Jon said work would be continued in here, but this ticket is also closed. I don't know Jira as well, is there a way to re-open this ticket? Is there an active clone of it somewhere?

Thanks.

Comment by Tom Boutell [ 07/Dec/09 ]

Reproducible test case:

[Remove your toprfx_doctrine_tmp_dirs etc. from your tmp folder, leftover classes from earlier crashes can cause unrelated errors, see separate ticket]

svn co http://svn.symfony-project.com/plugins/pkContextCMSPlugin/sandbox/branches/1.3 cmstest13
cd cmstest13
Create config/doctrine/schema.yml and add a trivial table so another bug won't be triggered (I opened a separate ticket on that):

Frog:
columns:
name: string

./symfony doctrine:build --all
./symfony doctrine:generate-migrations-diff

Fatal error: Class 'ToPrfxpkContextCMSSlot' not found in /private/var/folders/3H/3Hu3TTyjFtuvtN3D5tDUxU+++TI/Tmp/toprfx_doctrine_tmp_dirs/ToPrfxpkContextCMSButtonSlot.php on line 15

Note that pkContextCMSButtonSlot inherits from pkContextCMSSlot using Doctrine column aggregation inheritance. It appears that the autoloader just isn't trying to resolve inheritance relationships between classes in the toprfx_doctrine_tmp_dirs folder.

Comment by Robert Gruendler [ 14/Feb/10 ]

i've created a patch which fixes the issue, it's attached to the corresponding symfony ticket:

http://trac.symfony-project.org/ticket/7272

It modifies the core autoloading code and i'm not really familiar with the doctrine autoloading code, so please let me know if this
approach can be approved.

Comment by Jonathan H. Wage [ 29/Mar/10 ]

Hi, the patch cannot be committed. It is a blatant hack and cannot be applied. I have a solution I will commit soon though.

Comment by Jonathan H. Wage [ 29/Mar/10 ]

This should be fixed now: http://trac.symfony-project.org/changeset/28871

Thanks, Jon





Generated at Sat Oct 25 01:32:03 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.