[DC-207] Masked exception makes it very difficult to debug Created: 10/Nov/09  Updated: 10/Nov/09  Resolved: 10/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Connection
Affects Version/s: 1.2.0-ALPHA1, 1.2.0-ALPHA2, 1.2.0-ALPHA3, 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

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


 Description   

When you try to save an object, but the database does not exist, Doctrine throws a Doctrine_Transaction_Exception exception with the message "Rollback failed. There is no active transaction.".

But the real problem is that the database does not exit. The problem is in the Doctrine_Connection_UnitOfWork class around line 146:

        } catch (Exception $e) {
            // Make sure we roll back our internal transaction
            //$record->state($state);
            $conn->rollback();
            throw $e;
        }

The exception occurs because of "$conn->rollback();", and so the "throw $e;" is never reached.

We should probably throws an exception earlier about the fact that the database does not exist.






[DC-205] Problem with serial fields on PostgreSQL Created: 10/Nov/09  Updated: 10/Nov/09  Resolved: 10/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

Type: Bug Priority: Critical
Reporter: Antonio J. Garcia Lagar Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP 5.2.3
PostgreSQL 8.1



 Description   

When a new record is inserted into a table with an autoincrement primary key, the function Doctrine_Connection_UnitOfWork::processSingleInsert is called with the record to insert as parameter.

In Doctrine 1.1.x (http://trac.doctrine-project.org/browser/branches/1.1/lib/Doctrine/Connection/UnitOfWork.php#L590) this method was the responsible for getting the new ID value from the sequence, and with this value, it MODIFIED THE ARRAY OF FIELD VALUES to be inserted into the table.

Now this is done at a protected method named _assignSequence (http://trac.doctrine-project.org/browser/branches/1.2/lib/Doctrine/Connection/UnitOfWork.php#L629) which assigns the identifier to the record, but DOES NOT MODIFY THE ARRAY OF VALUES to be send to the database for the insert so when my db receive a null value for the ID column, generate a new one from the sequence.

The result is that the record gets an identifier which is different from the one that it really has on the database.

An example: on a db with a table 'foo' with two columns, 'id' and 'name', and a sequence called 'foo_id_seq' with a value of 6, when I try to insert a record with a named 'bar', the function $this->conn->insert($table, $fields); at http://trac.doctrine-project.org/browser/branches/1.1/lib/Doctrine/Connection/UnitOfWork.php#L595 receive as parameters 'foo' and array('id' =>7, 'name' =>'bar')

In Doctrine 1.2 the function at http://trac.doctrine-project.org/browser/branches/1.2/lib/Doctrine/Connection/UnitOfWork.php#L630 recevie as parameters 'foo' and array('name' =>'bar')

(Sorry for my poor English)



 Comments   
Comment by Antonio J. Garcia Lagar [ 10/Nov/09 ]

This error is a consecuence of the changeset 6635 (http://trac.doctrine-project.org/changeset/6635/branches/1.2/lib/Doctrine/Connection/UnitOfWork.php)

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

Thanks for the ticket. I committed a fix that will be in BETA2. Could you test and confirm that it fixes the issue?





[DC-204] [patch] Cloning or copying a query object keeps a reference to the previous hydrator Created: 09/Nov/09  Updated: 10/Nov/09  Resolved: 10/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

Type: Bug Priority: Major
Reporter: Ariel Arjona Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None

Attachments: Text File query_clone.patch    

 Description   

Upon cloning or copying a query object, the hydrator property still points to the original query. Changing it in the child object changes it for the parent object.

thanks to gnat42 for the patch






[DC-201] [PATCH] Level is oracle keyword (reopened #479) Created: 08/Nov/09  Updated: 10/Nov/09  Resolved: 10/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Nested Set
Affects Version/s: 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

Type: Improvement Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: Text File Level.patch    

 Description   

I created this ticket in connection to the http://trac.doctrine-project.org/ticket/479

The resolution was that it's fixed in http://trac.doctrine-project.org/changeset/3183/ - but it seems that it is fixed only in the changelog.

The LEVEL is an oracle keyword and the only way to use the NestedSet with Oracle is enabled quote identifiers.
We used this for about a year or more, but it is not so comfortable and this is the only reason why we are quoting identifiers.

But we started to use Oracle's spatial features and I was surprised that some oracle spatial functions are not able to work on quoted objects, and I started to use synonyms and extra columns with triggers as workaround. But it is so annoying and the patch is so simple



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

Thanks for the ticket and patch.





[DC-197] [patch] default model orderBy option breaks data-load task Created: 06/Nov/09  Updated: 10/Nov/09  Resolved: 10/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

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

Attachments: Text File doctrine12_orderby_select.patch    

 Description   

currently the default orderBy clause one can specify for models gets added to all queries, including DELETE and UPDATE.
This breaks data-load because it includes in the orderBy the table alias but currently only SELECT queries support aliases.

For example if I have the following schema:

Mytable:
options:

{ orderBy: name ASC }

columns:
name:

{ type: string(100), notnull: true }

The data-load task does a Doctrine::getTable('Mytable')>delete()>execute(); to clear the table before loading the fixtures which results in the following SQL:
DELETE FROM mytable ORDER BY m.name ASC

which errors out as the m alias was not defined.

Attached is the patch that makes only SELECT queries get the default orderBy clause from the option.






[DC-192] Doctrine_Import_Builder Missing Relation Alias When Using classPrefix Created: 05/Nov/09  Updated: 10/Nov/09  Resolved: 10/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

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

PHP 5.2.x, Windows (All)



 Description   

Doctrine_Import_Builder, line 383

$alias = (isset($relation['alias']) && $relation['alias'] !== $relation['class']) ? ' as ' . $relation['alias'] : '';

For example, if both class name and alias is "User" and we make use of classPrefix (i.e "Model_"), the generated class name will actually be "Model_User". The comparison of:

$relation['alias'] !== $relation['class']

does not cover the prefix, which lead to the missing of alias when generating models, i.e

$this->hasOne('Model_User', ...

instead of

$this->hasOne('Model_User as User', ...

Suggested fix:

$alias = (isset($relation['alias']) && $relation['alias'] !== $this->_classPrefix . $relation['class']) ? ' as ' . $relation['alias'] : '';






[DC-191] Doctrine_Migration->loadMigrationClassesFromDirectory fail when launched 2 times Created: 05/Nov/09  Updated: 10/Nov/09  Resolved: 10/Nov/09

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

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

daily symfony 1.3 svn



 Description   

When I need to create a Doctrine_Migration twice during a same php processus, the migrations version numbers get wrong.

In Doctrine_Migration->loadMigrationClassesFromDirectory method, I see :

        if (isset(self::$_migrationClassesForDirectories[$directory])) {
            $migrationClasses = (array) self::$_migrationClassesForDirectories[$directory];
            $this->_migrationClasses = array_merge($migrationClasses, $this->_migrationClasses);
        }

The problem is that array_merge loose the array keys. In the $this->_migrationClasses context, array keys are very important because they are the version numbers.

So when if (isset(self::$_migrationClassesForDirectories[$directory])) is true ( ie the second time we use the Doctrine_Migration classs ) all the migrations versions get wrong.

I hope my description is clear enough.



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

After looking at it, that code didn't make sense and it could never work, you are right. I removed it. Now if you call that function twice it will reset everything and reload the classes from the configured directories.





[DC-190] Fatal error while connecting after an reset of the Doctrine_Manager Created: 04/Nov/09  Updated: 10/Nov/09  Resolved: 10/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Attributes
Affects Version/s: 1.2.0-ALPHA3, 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

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

osx10.6.1, php5.3.0



 Description   

Doctrine_Manager::connection('sqlite::memory:');
Doctrine_Manager::resetInstance();
Doctrine_Manager::connection('sqlite::memory:');
Fatal error: Call to a member function onOpen() on a non-object in ...../Doctrine/Connection.php on line 221

which is $this->getAttribute(Doctrine_Core::ATTR_LISTENER)->onOpen($this);

The Doctrine_Core::ATTR_LISTENER attribute is not set in the connection nore in the manager... This is because Doctrine_Manager::resetInstance does remove all attributes but Doctrine_Manager::setDefaultAttributes does not allow to set the default attributes twice.

This method can only run once, because it use a local static $init variable and since Doctrine_Manager is a Singleton the init value should stored within the instance.

What happens :
1. In Doctrine_Manager::setDefaultAttributes() the Doctrine_Core::ATTR_LISTENER is set to new Doctrine_EventListener().
2. A connection get its attributes from the manager when not available in the connection.
3. When Doctrine_Manager::reset() is called the attributes are gone and should be set again...
4. However because the Doctrine_Manager::setDefaultAttibutes method only can run once (a check is set in a static local boolean) the listener is not recreated and thus subsequent connections will fatally fail

patch by
A fix is simple and I have it running locally...

1. add an private $_inited or $_defaultAttributesSet property to Doctrine_Manager, defaults to false;
2. on Doctrine_Manager::reset reset it to its default (false)
3. on Doctrine_Manager::setDefaultAttibutes do nothing when the property equals true, but when the property is false proceed with setting the default attributes...






[DC-186] Patch to correct CLI tests Created: 04/Nov/09  Updated: 04/Nov/09  Resolved: 04/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Cli
Affects Version/s: 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

Type: Improvement Priority: Major
Reporter: Dan Bettles Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP 5.3, Darwin, Macbook


Attachments: File Cli_testcase_corrections.diff    

 Description   

Enclosed is a little patch to correct my CLI tests.

The patch wraps test runs on the CLI in an output buffer to prevent output to the console when the unit tests are run. This output from the CLI could be mistaken for errors, but it's expected and only looks unfriendly - no errors / exceptions are thrown.






[DC-184] Doctrine_Connection_Statement->execute() gerenates a PHP warning with Doctrine 1.2 BETA1 Created: 04/Nov/09  Updated: 04/Nov/09  Resolved: 04/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Connection
Affects Version/s: 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

Type: Bug Priority: Minor
Reporter: Vincent Delhommeau Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows XP pro SP2
Apache Version Apache/2.2.10 (Win32) PHP/5.2.6

php -v
PHP 5.2.6 (cli) (built May 2 2008 18:02:07)
Zend Engine v2.2.0
Xdebug v2.0.3

mysql -V
mysql Ver 14.12 Distrib 5.0.67, for Win32 (ia32)

Doctrine.php 6489 2009-10-12 20:21:01Z



 Description   
// switch between 1.2 ALPHA3 and 1.2 BETA1
//require_once('../CMS/Doctrine-1.2.0-ALPHA3-Sandbox/lib/Doctrine.php');
require_once('../CMS/Doctrine-1.2.0-BETA1-Sandbox/lib/Doctrine.php');

spl_autoload_register(array('Doctrine', 'autoload'));
$manager = Doctrine_Manager::getInstance();
$conn = Doctrine_Manager::connection('mysql://user:password@localhost/test');

// table creation (done with Doctrine 1.2 ALPHA3)
//$conn->export->createTable('test', array('name' => array('type' => 'string')));
//$conn->execute('INSERT INTO test (name) VALUES (?)', array('vince'));

// retreive data from table
$stmt = $conn->prepare('SELECT * FROM test');
$stmt->execute();
$results = $stmt->fetchAll();
var_dump($results);

In the code above, $stmt->execute(); generates a warning (but the data is retreived from the table) under 1.2 BETA1 (no problem with 1.2 ALPHA3) :

Warning: Invalid argument supplied for foreach() in F:\Vince\devweb\CMS\Doctrine-1.2.0-BETA1-Sandbox\lib\Doctrine\Connection\Statement.php on line 245
Line 245 is part of a block of code added in lib/Connection/Statement.php (execute function) in 1.2 BETA1 :

$pos = 0;
 foreach ($params as $key => $value) {
    $pos++;
    $param = is_numeric($key) ?  $pos : $key;
    if (is_resource($value)) {
        $this->_stmt->bindParam($param, $params[$key], Doctrine_Core::PARAM_LOB);
    } else {
        $this->_stmt->bindParam($param, $params[$key]);
    }
}

The call stack from xdebug shows the function : Doctrine_Connection_Statement->execute()

I see the warning because of my php.ini settings : error_reporting = E_ALL
I mention this issue because sometimes a warnig may result in a more important error later in the code.






[DC-180] [PATCH] Unique index name for column aggregation key column Created: 04/Nov/09  Updated: 04/Nov/09  Resolved: 04/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

Type: Bug Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: Text File RecordAbstract.php.patch    

 Description   

When using column aggregation colum with the same name on multiple models, and exporting schema to database, I have a collisions with names in Oracle (I think others are affected too).

{{
CREATE INDEX "type" ON "nt_organism_property" ("type")
CREATE INDEX "type" ON "nt_property" ("type")
CREATE INDEX "type" ON "st_node" ("type")
}}

I propose to prefix the index name with the table name






[DC-179] Wrong length estimation in Doctrine_Validator->validateLength() if locale sets decimal point other than "dot" Created: 04/Nov/09  Updated: 04/Nov/09  Resolved: 04/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Validators
Affects Version/s: 1.2.0-ALPHA1
Fix Version/s: 1.2.0-BETA2

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

Apache/2.2.11 (Win32) PHP/5.2.11, windows vista


Attachments: File Validator.php    

 Description   

Test case:
1) set locale: setlocale(LC_ALL, "") (on windows it sets current international control panel settings), in case of Polish locale it changes decimal point to ',' (comma)
2) try to save value "12,12" of decimal type field (mysql type):

{ type: decimal(4), scale: 2 }

,
3) it gives you validation error (length)

Summary:
Doctrine_Validator->validateLength() could not count length properly.

Idea:
I changed dot character in explode function to proper env character:

// changes start
$localeInfo = localeconv();
$e = explode($localeInfo["mon_decimal_point"], $value);
// changes end

It works for me.

Enclosed Validator.php






[DC-178] Import Builder doesn't use default table class name Created: 04/Nov/09  Updated: 04/Nov/09  Resolved: 04/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Import/Export, Inheritance, Record
Affects Version/s: 1.2.0-ALPHA1, 1.2.0-ALPHA2, 1.2.0-ALPHA3, 1.2.0-BETA1
Fix Version/s: 1.2.0-BETA2

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

Attachments: Text File DC-178.patch    

 Description   

I use Symfony 1.2.9 with Doctrine 1.2 trunk.

I also make use of the new Doctrine's feature to specify custom table class. For that, in the config/ProjectConfiguration.class.php I have the following code:

   public function configureDoctrine(Doctrine_Manager $manager)
   {
      ...
      $manager->setAttribute(Doctrine::ATTR_TABLE_CLASS, 'Platform_DoctrineTable');
      ...
   }

And that works fine. But when I comment out this line and re-generate model classes, I get broken table class definitions like:

class AccountTable extends 
{

}

Notice the lack of base class name.

It seems the problem resides in Doctrine_Import_Builder's constructor:

    public function __construct()
    {
        $this->_baseTableClassName = Doctrine_Manager::getInstance()->getAttribute(Doctrine_Core::ATTR_TABLE_CLASS);
        $this->loadTemplate();
    }

So, the default value of $this->_baseTableClassName always overwrites by Doctrine_Core::ATTR_TABLE_CLASS attribute value.



 Comments   
Comment by Eugene Janusov [ 04/Nov/09 ]

Proposed patch attached.





[DC-156] missing foreignType: one in code example if "Foreign Key Associations" in chapter "Defining Models" Created: 29/Oct/09  Updated: 10/Nov/09  Resolved: 10/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 1.2.0-BETA2

Type: Improvement Priority: Minor
Reporter: Dominique Comte Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

N/A


Attachments: Text File en_defining-models.patch    

 Description   

in the code example for "One-to-one" relation, the "one-to-one" relation is built by extending the BaseUser instead of adding 'foreignType' => 'one' to the setUp.

if done this way, the next Tip and Note have to be rewritten, and the next code example becomes unnecessary.

an attempt at it is attached.






Generated at Thu Jul 24 17:53:54 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.