[DC-175] New hardDelete() on Soft Delete Template creates blank records Created: 03/Nov/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

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

Attachments: HTML File patch    

 Description   

When using the new hardDelete() in the SoftDelete template, the postDelete() listener is saving a blank record because it calls ->save() on the record, even if the record was hard deleted.

    public function postDelete(Doctrine_Event $event)
    {
      $event->getInvoker()->save();
    }

should be

 
    public function postDelete(Doctrine_Event $event)
    {
      if ( ! $this->_options['hardDelete']) {
        $event->getInvoker()->save();
      }
    }





[DC-173] Error generating models from db when a table name is a reserved word in PostgreSQL Created: 03/Nov/09  Updated: 27/Nov/09  Resolved: 03/Nov/09

Status: Resolved
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.2.0-ALPHA3
Fix Version/s: 1.2.0-BETA1

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

PostgreSQL 8.1, PHP 5.2



 Description   

I'm getting an exception when generating models from db because I have a table named 'role' which is a reserved word, as you can see at http://www.postgresql.org/docs/8.1/static/sql-keywords-appendix.html

I have a table named 'role_permission' which has a foreign key pointing to table 'role'. When Doctrine tries to find the related tables using 'Doctrine_Import_Pgsql::listTableRelations()', the executed SQL returns:
FOREIGN KEY (role_id) REFERENCES "role"(role_id) ON DELETE CASCADE
with the table name role quoted as it is a reserved word.

My workaround is to change Doctrine_Import_Pgsql line 281 from:

$relations[] = array('table' => $values[2],

to:

$relations[] = array('table' => (strpos($values[2],'"') === 0)?substr($values[2],1,-1):$values[2],



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

This was already fixed last night.

Comment by Andreas Möller [ 27/Nov/09 ]

I have a similar issue when attempting to generate SQL from models previously generated from Yaml schema files.

When defining a schema as

Resource:
columns:
id:
type: integer(4)
autoincrement: true
primary: true

an exception is thrown with the message 'no valid table name specified'. When adding a tablename to the schema

Resource:
tableName: resourcexx

the problem persists.

I believe I did not have this problem a couple of updates from the SVN ago, will track it down and maybe open a ticket. I am using Doctrine 1.2.0-ALPHA3.





[DC-172] change 6611 wrong Created: 02/Nov/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

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

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

i think the change has a logic error



 Description   

see line 95 in branches/1.2/lib/Doctrine/Connection/UnitOfWork.php

if ($ids) {
$record->unlinkInDb($alias, array());
} else if ($ids) {
$record->unlinkInDb($alias, array_keys($ids));
}



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

Thanks for catching that.





[DC-171] make it possible to force deletion when using softdelete Created: 02/Nov/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

Type: New Feature Priority: Major
Reporter: Lukas Kahwe Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

it would be nice to be able to force deleting when using softdelete. right now it seems like there is no way to still be able to do a real DELETE.
http://www.doctrine-project.org/documentation/manual/1_1/en/behaviors:core-behaviors:softdelete

something like $record->delete(true);

take for example some undo feature. there might be a point where i want to purge the possibility to do an undo (like at the end of the session).






[DC-169] replace() method does not affect Timestampable fields Created: 02/Nov/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

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

LAMP, symfony 1.3.0-BETA1



 Description   

I have a Timestampable behavior on a table. If I create or edit an object of this table using the ->replace() method instead of ->save(), the Timestampable fields (created_at and updated_at by default) are not changed.






[DC-167] Adding a foreign key to the uniqueBy option of a Sluggable doesn't work Created: 01/Nov/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

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

A freshly installed symfony 1.3-BETA1, but the doctrine svn still has it



 Description   

I'm trying to set the uniqueBy option of a Sluggable to a foreign key (in an articles table, I want the slug to be unique by category). This fails because the query checking if the slug exists doesn't return any records, as it doesn't use the correct where paramter.
The problem is in Doctrine/Template/Listener/Sluggable.php:172, adding the whereParam expects a value, but a class (containing the relationship object) is given.

        foreach ($this->_options['uniqueBy'] as $uniqueBy) {
            if (is_null($record->$uniqueBy)) {
                $whereString .= ' AND r.'.$uniqueBy.' IS NULL';
            } else {
                $whereString .= ' AND r.'.$uniqueBy.' = ?';
                $whereParams[] =  $record->$uniqueBy;
            }
        }





[DC-165] outdated symfony Yaml parser causes troubles Created: 31/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: File Parser
Affects Version/s: 1.0.12, 1.1.4, 1.2.0-ALPHA1
Fix Version/s: 1.2.0-BETA1

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


 Description   

all doctrine versions use an imported and modified version of sfYaml.
Either that needs to be changed to an external, or bugfixes need to be ported.
see this ticket from symfony trac:
http://trac.symfony-project.org/ticket/7496

I wanted to use some yaml in a fixture to populate data for the "array"-Fieldtype.

In the fixture I used:

items:
  -
    name:           temp_zone_1
    fieldLabel:     Temp. Zone 1 [°C]
    value:          997
    minValue:       0
    maxValue:       3000
...

the resulting serialized array in the table array looked like:

s:5:"items";a:9:{i:0;a:5:{s:4:"name";s:11:"temp_zone_1";s:10:"fieldLabel";s:18:"Temp. Zone 1 [°C]";s:5:"value";s:3:"997";s:8:"minValue";i:0;s:8:"maxValue";s:4:"3000";}...

There you can easily see, that "value" is now a string, "minValue" an integer (why?) and maxValue another string. This went awfully wrong somewhere.

= Workaround and/or solution =
I took the current parser from `lib/yaml/sfYamlParser.php` and copied it into the existing Parser in `lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Parser/YamlSf/Parser.php`. That fixed the problem.

== Additional Information ==

used Version in Symfony 10832 2008-08-13
used Version in sfDoctrinePlugin 8869 2008-05-09

HTH,
Michael






[DC-164] Validator throws out a 'boolean' with null value. Created: 31/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

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

Fedora 10, symfony 1.2, php 5.2.9, postgresql 8.4.1, can't tell what version of Doctrine I have.



 Description   

I didn't set a value into a boolean column, reckoning that null would count as false.

But saving the record fails validation, and this appears to be because Doctrine_Validator::isValidType contains

case 'boolean':
return is_bool($var) || (is_numeric($var) && ($var == 0 || $var == 1));

So it will not accept a null value, and furthermore reports the failure not as a data error but (confusingly) as a type error.

I checked the documentation to see if it said that I could not use a null value (I would regard this as an unnecessary restriction, but at least if it were documented, that would be consistent).

On the contrary, the Doctrine ORM book, Chapter 7, in the 'Boolean' section, says "Ternary logic is possible by using null as the third possible value that may be assigned to fields of this type."!

Add this to the fact that I haven't found any documentation about using Doctrine_Validator_Exception - not even API documentation, and I am not impressed with my first experiences with Doctrine.



 Comments   
Comment by Roman S. Borschel [ 31/Oct/09 ]

This is the wrong project. Please submit these bugs to the Doctrine1 project. I already moved the 2 tickets you created. Just create any more in the Doctrine 1 project.

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

This is already fixed in Doctrine 1.2 as well.





[DC-163] Validator throws out a data type which the schema processing has accepted Created: 31/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

Type: Bug Priority: Major
Reporter: Colin Fine Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Fedora 10, symfony 1.2, postgresql 8.4.1. I have been unable to find any information as to which version of Doctrine I have: it came with symfony 1.2



 Description   

Doctrine accepts 'char' in the (yml) schema, and creates the database and model.
Then an attempt to save a record raises a Doctrine_Validator_Exception, which turns out to contain no validation message, but just the cryptic
[_errors:protected] => Array
(
[nickname] => Array
(
[0] => type
)

)

[_validators:protected] => Array
(
)

Only by looking at the source did I discover that what this means is that the validator does not accept the column type 'char' - because it's not hard-coded in Doctrine_Validator::isValidType.

I've vacillated over whether to classify this as 'Major' or Minor': once I've realised what's going on, it's easy to work round; but it is a show-stopper for a Doctrine novice.



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

This is already fixed in the Doctrine 1.2 branch which comes with symfony 1.3





[DC-162] Doctrine_Migration_Builder fail to buildChangeColumn() Created: 30/Oct/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

Status: Resolved
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.0-ALPHA3
Fix Version/s: 1.2.0-BETA1

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

Symfony 1.3 daily svn



 Description   

Doctrine_Migration_Builder->buildChangeColumn contains a simple error.

return "        \$this->changeColumn('" . $tableName . "', '" . $columnName. "', '" . $length . "', '" . $type . "', " . $this->varExport($column) . ");";

When I look Doctrine_Migration_Base->changeColumn declaration, i see

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

The $length and $type parameters are inverted. It makes all column changes fail.

Thank you for your work, Doctrine is great !



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

This has already been fixed in another issue/commit.





[DC-159] No use of Offset in the Limit / Offset Documentation Created: 30/Oct/09  Updated: 30/Oct/09  Resolved: 30/Oct/09

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

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

any



 Description   

There is no mentioning how to use the offset funktion in the "LIMIT and OFFSET clauses" chapter in the Doctrine 1.1 Documentation.

Some Example should feature:

->limit(12)
->offset(3)

to show how to use it.



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

Enhanced this for the 1.2 documentation since 1.1 end of life is approaching.

Comment by Pascal Helfenstein [ 30/Oct/09 ]

thanks





[DC-158] Postgresql Import does not recognize all parts of a composite primary key as primary keys Created: 29/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

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

Doctrine 1.1 from current SVN with PostgreSQL 8.3.8


Attachments: Text File pgsql_import.patch    

 Description   

If a PostgreSQL table has a composite primary key, Doctrine import ("generate-models-db") will only mark the first column of the composite key as primary. This is due to a bug in Doctrine_Import_Pgsql.

I have attached a short patch against the current 1.1 branch (revision 6580). The version 1.2 seems to have the same problem.
I have tested the patch with PostgreSQL 8.3.8.



 Comments   
Comment by Moritz Breit [ 02/Nov/09 ]

Small test case for this bug:

Database schema:

schema.sql
CREATE TABLE testa (
  id bigint NOT NULL,
  CONSTRAINT testa_pkey PRIMARY KEY (id)
);

CREATE TABLE testb (
  id bigint NOT NULL,
  CONSTRAINT testb_pkey PRIMARY KEY (id)
);

CREATE TABLE testa_testb (
  testa bigint NOT NULL,
  testb bigint NOT NULL,
  CONSTRAINT testa_testb_pkey PRIMARY KEY (testa, testb),
  CONSTRAINT fktesta FOREIGN KEY (testa) REFERENCES testa (id),
  CONSTRAINT fktestb FOREIGN KEY (testb) REFERENCES testb (id)
);

This is a typical many-to-many relationship with a mapping table.
Note that testa_testb has a composite primary key with two columns, testa and testb.

Generated code before applying the patch (generateModelsFromDb):

BaseTestaTestb.php
abstract class BaseTestaTestb extends Doctrine_Record
{
    public function setTableDefinition()
    {
        $this->setTableName('testa_testb');
        $this->hasColumn('testa', 'integer', 8, array(
             'type' => 'integer',
             'length' => 8,
             'unsigned' => false,
             'primary' => true,
             ));
        $this->hasColumn('testb', 'integer', 8, array(
             'type' => 'integer',
             'length' => 8,
             'unsigned' => false,
             'notnull' => true,
             'primary' => false, // This should be true
             ));
    }
...

Generated code after applying the patch:

BaseTestaTestb.php
abstract class BaseTestaTestb extends Doctrine_Record
{
    public function setTableDefinition()
    {
        $this->setTableName('testa_testb');
        $this->hasColumn('testa', 'integer', 8, array(
             'type' => 'integer',
             'length' => 8,
             'unsigned' => false,
             'primary' => true,
             ));
        $this->hasColumn('testb', 'integer', 8, array(
             'type' => 'integer',
             'length' => 8,
             'unsigned' => false,
             'primary' => true,
             ));
    }
...




[DC-155] Missing part of the description for code examples in "Working with Models" chapter Created: 29/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Documentation
Affects Version/s: 1.1.4
Fix Version/s: 1.2.0-BETA1

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

N/A


Attachments: Text File en_wwm.patch    

 Description   

in chapter "Working with models", explanations for 2 code examples are missing a part : ", excluding the group named Group 2"

patch attached.






[DC-154] Documentation fixes in several chapters Created: 28/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Documentation
Affects Version/s: 1.1.4
Fix Version/s: 1.2.0-BETA1

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

N/A


Attachments: Text File en_fixes.patch    

 Description   

several fixes attached as patch :

  • missing "have" in note in introduction chapter
  • "DQL" instead of "SQL" in explanation for getSql in DQL chapter
  • explanations uses property "password", whereas the example code uses "description" in chapter Working with models
  • extra line breaks in Synchronize with Array in chapter Working with models
  • word "their" was used instead of "there" in several sentences





[DC-153] Some pieces of Doctrine's internal code can't work properly without a default connection Created: 28/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

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

Attachments: Text File DC-153.v2.3.patch    

 Description   

For details see thread in doctrine-dev group.



 Comments   
Comment by Eugene Janusov [ 28/Oct/09 ]

Proposed patch, v1
Proposed patch, v2
Proposed patch, v2.2 — without white-spaces
Proposed patch, v2.3

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

I think it is a requirement that you always have a default connection. Why don't you?

Comment by Eugene Janusov [ 03/Nov/09 ]

Why it should be a requirement?

We use several connections to different databases and with different privileges, and we would like to enforce our developers to always specify a particular connection.

In anyway, it's obviously a bug, because currently Doctrine can use wrong connection.

Comment by Eugene Janusov [ 03/Nov/09 ]

I've missed one line change in v2.2.





[DC-152] isModified deep isn't working when only deep objects are modified Created: 28/Oct/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

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

Type: Bug Priority: Major
Reporter: Rodolfo Schulz de Lima Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

linux, apache, php 5.3


Attachments: File doctrine_ismodified_deep.diff    

 Description   

Record::isModified(true) isn't working when only a subobject is modified (it returns false).
The attached patch corrects the problem.






[DC-151] Doctrine_Collection::loadRelated() issues with empty collection and handling with no name parameter Created: 28/Oct/09  Updated: 30/Oct/09  Resolved: 30/Oct/09

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

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

Attachments: Text File Collection.php.patch    

 Description   

When no name is passed, the list variable isnt passed to the where() method call. Also in all cases an empty $list variable isnt handled properly.






[DC-148] When running cli tasks and there's an exception/error - it's helpful to have detailed information displayed Created: 27/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

Type: New Feature Priority: Minor
Reporter: D Ashwood Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Cli Tasks



 Description   

We don't always get enough information when an exception happens to track down where the issue is.
It would be helpful if the tablename and/or the SQL statement was also displayed to help track down problems.

When trying to load a fixture file I was receiving the following:
[Doctrine_Connection_Mysql_Exception]
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'created_at' cannot be null

As you can see - it doesn't help much as it doesn't display the table/class that's the created_at column is on.

As quick fix - I modified the rethrowException method in Doctrine_Connection to include some information from the invoker (not a great fix - I should really dig deeper and see if there's a __toString() method on classes that can be passed as the invoker):

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
    /**
     * rethrowException
     *
     * @throws Doctrine_Connection_Exception
     */
    public function rethrowException(Exception $e, $invoker)
    {
        $event = new Doctrine_Event($this, Doctrine_Event::CONN_ERROR);

        $this->getListener()->preError($event);
        
        $name = 'Doctrine_Connection_' . $this->driverName . '_Exception';
        
        $exc  = new $name($e->getMessage() . "\n" . $invoker->getQuery(), (int) $e->getCode());
        if ( ! isset($e->errorInfo) || ! is_array($e->errorInfo)) {
            $e->errorInfo = array(null, null, null, null);
        }
        $exc->processErrorInfo($e->errorInfo);

         if ($this->getAttribute(Doctrine_Core::ATTR_THROW_EXCEPTIONS)) {
            throw $exc;
        }
        
        $this->getListener()->postError($event);
    }





[DC-147] In doctrine 1.2 load_data fails with a bogus error when id holders are repeated Created: 27/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

Status: Resolved
Project: Doctrine 1
Component/s: Data Fixtures
Affects Version/s: 1.2.0-ALPHA3
Fix Version/s: 1.2.0-BETA1

Type: Bug Priority: Minor
Reporter: D Ashwood Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 1
Labels: None
Environment:

Ubuntu, PHP 5.3, Symfony 1.3-beta, MySQL 5.1


Attachments: File DC147TestCase.php     File DC147TestCase.php    

 Description   

Schema fragment:
Invoice:
actAs:
Timestampable: ~
tableName: invoice
columns:
id:
type: integer(4)
primary: true
autoincrement: true
billingDate:
type: date
dueDate:
type: date
hostingAccount_id:
type: integer(4)
relations:
invoiceItems:
class: InvoiceItem
local: id
type: many
foreign: invoice_id
foreignType: one

#
InvoiceItem:
actAs:
Timestampable: ~
tableName: invoiceItem
columns:
id:
type: integer(4)
primary: true
autoincrement: true
name:
type: string(100)
quantity:
type: integer(4)
cost:
type: decimal(10)
scale: 2
notnull: false
default: null
invoice_id:
type: integer(4)

With the following fixture fragment:

Invoice:
testInvoice01:
billingDate: "2009-11-11"
dueDate: "2009-11-16"
owningAccount: TestAcc01
invoiceItems:
invItem01:
name: TestLine01
quantity: 2
cost: 12.99
invItem02:
name: TestLine02
quantity: 1
cost: -2.50

testInvoice02:
billingDate: "2009-11-11"
dueDate: "2009-11-21"
owningAccount: TestAcc01
invoiceItems:
invItem01:
name: TestLine03
quantity: 2
cost: 12.99
invItem02:
name: TestLine04
quantity: 1
cost: -2.50

The reuse of the invItem01 & invItem02 tags - even as children of separate parents causes an error.
The reported error was very confusing:

[Doctrine_Connection_Mysql_Exception]
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'created_at' cannot be null

Making the child tags unique fixed the issue.
The same fixture loaded without problems in Doctrine 1 (I think 1.0.18 but it's not listed in the released versions above).



 Comments   
Comment by Jason B [ 31/Oct/09 ]

I've experienced the same bug. We moved from symfony 1.2 to 1.3 for beta testing.

This example might help as well.
Team:
NCAAF-BostonCollege:
Sport: NCAAF
name: Boston College Golden Eagles
logo: boston_college.gif
Conference: NCAAF-ACC
Division: NCAAF-ACC-Atlantic
TeamAlias:
a1:

{ alias: BOSTON COLLEGE }

a2:

{ alias: BC }

NCAAF-FloridaState:
Sport: NCAAF
name: Florida State Seminoles
logo: florida_state.gif
Conference: NCAAF-ACC
Division: NCAAF-ACC-Atlantic
TeamAlias:
a1:

{ alias: FLORIDA STATE }

a2:

{ alias: FSU }

a3:

{ alias: Florida St }

In 1.0.x we were able to load all of these teams with x number of aliases. In 1.2 when TeamAlias was actAs: Timestampable we got the result as mentioned in the bug description. But when we removed the Timestampable the a1 aliases would load but none of the a2's or a3's...

Hope that helps. Thanks guys.

Comment by Jason B [ 31/Oct/09 ]

When I reverted this changeset:
http://trac.doctrine-project.org/changeset/6377/branches/1.2/lib/Doctrine/Data/Import.php

I was able to import all my related children.

Comment by Jason B [ 01/Nov/09 ]

Attached a working test case to satisfy this bug. Adapted from:
http://trac.doctrine-project.org/browser/branches/1.2/tests/Ticket/DC23bTestCase.php
So this test also tests some of the functionality of:
http://www.doctrine-project.org/jira/browse/DC-23

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

It is required that every key is unique now. I changed your test case and it passes now.





[DC-146] GenerateMigrationsDiff task does not use new order of changeColumn() Created: 27/Oct/09  Updated: 30/Oct/09  Resolved: 30/Oct/09

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

Type: Bug Priority: Critical
Reporter: Dennis Benkert Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: File Builder.php.diff    

 Description   

The GenerateMigrationsDiff task generates migrations which still use the old ordering of parameters of changeColumn().

This is how it gets generated:

$this->changeColumn('my_table', 'my_column', '25', 'timestamp', array(
'notnull' => '1',
));

Why it should be like this

$this->changeColumn('my_table', 'my_column', 'timestamp', '25', array(
'notnull' => '1',
));

I also added a patch to fix this.






[DC-144] Doctrine_Manager::getConnectionForComponent() should use Doctrine_Core::modelsAutoload() Created: 27/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

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

Attachments: Text File DC-144.patch    

 Description   

Doctrine_Manager::getConnectionForComponent() tries to pre-load given component using Doctrine_Core::autoload().
But it seems it should be modelsAutoload() instead, because just autoload() has nothing to do with model classes.

See also corresponding topic in the doctrine-dev group.



 Comments   
Comment by Eugene Janusov [ 27/Oct/09 ]

Trivial patch.





[DC-141] Invalid fix [6568] for DC-132 Created: 26/Oct/09  Updated: 30/Oct/09  Resolved: 30/Oct/09

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

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


 Description   

Changeset [6568] looks incorrect, it always binds parameters as if they were positional thus not by name :MYPARAM. Therefore for queries with named parameters a PDO exception will be thrown.

Btw, I wanted to reopen Jira ticket DC-132 for this, but how do I do that?






[DC-137] Doctrine_Record_Generator does not autoload classes Created: 23/Oct/09  Updated: 02/Dec/09  Resolved: 02/Nov/09

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

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

CentOS 5.3, PHP 5.2.5



 Description   

Using the versionable behavior creates dynamic classes and does not autoload the models that are defined. Removing the false flag from if ($this->_options['generateFiles'] === false && class_exists($this->_options['className']. false )) { line will fix the issue



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

Hmm. I remember once upon a time this was this way for a reason. Can you show some code for what you're doing so I can test this myself. Are you writing the generated files to disk somewhere?

Comment by Brian Voelschow [ 28/Oct/09 ]

Jonathan,
I wrote a model class so we can access the version history and display it in an application. The code that we are using is just trying to save versions when we have database delegation. We enabled the delegation code in our X_Doctrine_Record class. When debugging the calls we noticed that the correct model does not get loaded, but the generated model did. We need the model that we created so that our delegation will work and save the version to the master DB.

Steps to Reproduce:
1. Add versionable behavior to an existing model
2. Create a model for the version table
3. Try to save an object. Error returned - If you do not allow saves on your slave connection

Comment by Jonathan H. Wage [ 28/Oct/09 ]

I see. The part where you create your own model class is not how this is intended to work. It is intended that you let Doctrine generate the model class for you.

Comment by Brian Voelschow [ 28/Oct/09 ]

Understood that this is not how the code is intended to work, but without having a model there is no way to get the complete history. The only way right now to get the complete history of a record would be to loop through the version records after getting the max version from the original record.

Comment by Jonathan H. Wage [ 28/Oct/09 ]

I'm failing to understand. The behavior generates a model for you named ModelNameVersion and ModelName hasMany ModelNameVersion, no?

Comment by Brian Voelschow [ 28/Oct/09 ]

The relationship was not created. We are adding it and going to some testing. Get back to you

Comment by Brian Voelschow [ 28/Oct/09 ]

The relationship worked on the generated class, but there is still an issue. Without creating a model for the version table, there is no way to use our delegation code. This still causes the problem of saving to the slave. or reading from the master.

Comment by Jonathan H. Wage [ 28/Oct/09 ]

Hmm. The model does exist though. It is called "ModelNameVersion" and it is auto generated for you by Doctrine_Record_Generator. It also has options to write the generated model to a path somewhere.

Comment by Brian Voelschow [ 28/Oct/09 ]

Without autoloading the class by removing the false flag in the generator code, the saved model will never get loaded. Another issue is that when trying to use the saved generated class, we get an error that it cannot find the id field that it created. The id field does not exist in the table.

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

We'll give this change a try. If it causes some issues for people we may have to revert it. I remember that false argument being there for a reason but I can't remember and none of our tests pass without it.

Comment by Brian Voelschow [ 03/Nov/09 ]

If your tests are not passing then there must be a reason for it to be set to false. I think a configuration option here would be a better solution. Similar to the Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES setting.

Comment by Adam Jensen [ 20/Nov/09 ]

For what it's worth, I'm running r6785 of the http://svn.doctrine-project.org/tags/1.2.0-BETA3 tag, and the absence of the false argument is causing me some annoying issues.

Based on the documentation/parameters/etc., I'm assuming both of the following use cases are supposed to be possible:

A. The ModelNameVersion class is generated on-the-fly as necessary, and never stored in the filesystem.
B. The ModelNameVersion class is generated once, stored in the filesystem, and subsequently autoloaded from there.

Now, from what I can tell, both use cases work correctly even without the false argument on line 159; however, in case A, a PHP warning can be generated if one of the registered autoloaders doesn't check to see if the file exists before including it. This appears to be the case with Zend_Loader_Autoloader_Resource, for instance; my guess is that it's designed that way such that non-existing files produce the same warnings you'd get if you tried to include them manually ...but it doesn't play nice with Doctrine's expectations here (and heck, it may well be a bug on their part to write it that way).

These warnings don't appear to affect any functionality ...the line 159 conditional still turns up false, allowing the class to be generated on the fly. All the same, I'd prefer not to have to turn off E_WARNING on my development machine just to avoid seeing these. Since Doctrine can't really guarantee that all of the autoloaders registered with SPL are properly avoiding such blind includes, it may make more sense to leave the false argument in place and avoid the warnings.

Of course, I don't know what effect that would have on use case B; my guess is that it'd break, since that's what this issue was originally about Is there another solution available that satisfies both use cases without raising any errors?

Thanks!
Adam

Comment by Joël [ 02/Dec/09 ]

Hi !

I'm using Zend Framework and Doctrine and I got warnings with Doctrine_Template_Searchable that was trying to load the Index classes of the Searchable behaviour.
And as you said, with the false argument of get_class() Zend_Framework failed...

I tried with 1.9.6 of Zend_Framework and it still failed, although they seem to say in your external reference ([ZF-8364] Zend_Loader_Autoloader_Resource::autoload() should return false if no match is found) that it would be fixed in release 1.9.6...

Here it is... it was just to point it out

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

Doesn't the autoloader have an option to check if the file exists before trying to include it?





[DC-135] Nested i18n versionable behaviour Created: 23/Oct/09  Updated: 13/Dec/09  Resolved: 02/Nov/09

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

Type: Bug Priority: Major
Reporter: Michael Piecko Assignee: Jonathan H. Wage
Resolution: Can't Fix Votes: 0
Labels: None


 Description   

Sorry to bring this up again (http://trac.doctrine-project.org/ticket/1708), but the current ALPHA 3 works perfectly on MySQL and fails on PostgreSQL. I tried the simple wiki example on a fresh project. I posted it already on google groups, but it seems this is the right place for that: http://groups.google.com/group/doctrine-user/browse_thread/thread/32208d921dffb8b3/63eb7337015f4415?show_docid=63eb7337015f4415

This is the generated postgresql sql file:

CREATE TABLE wiki_translation_version (id BIGINT, lang CHAR(2), title VARCHAR(255), content TEXT, version BIGINT, PRIMARY KEY(id, lang, version));
CREATE TABLE wiki_translation_index (id BIGINT, lang CHAR(2), keyword VARCHAR(200), field VARCHAR(50), position BIGINT, PRIMARY KEY(id, lang, keyword, field, position));
CREATE TABLE wiki_translation (id BIGINT, title VARCHAR(255), content TEXT, lang CHAR(2), version BIGINT, slug VARCHAR(255), PRIMARY KEY(id, lang));
CREATE TABLE wiki (id BIGSERIAL, created_at TIMESTAMP NOT NULL, updated_at TIMESTAMP NOT NULL, PRIMARY KEY(id));
CREATE UNIQUE INDEX sluggable ON wiki_translation (slug);
ALTER TABLE wiki_translation_version ADD CONSTRAINT wiki_translation_version_id_wiki_translation_id FOREIGN KEY (id) REFERENCES wiki_translation(id) ON UPDATE CASCADE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE;
ALTER TABLE wiki_translation_index ADD CONSTRAINT wiki_translation_index_id_wiki_translation_id FOREIGN KEY (id) REFERENCES wiki_translation(id) ON UPDATE CASCADE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE;
ALTER TABLE wiki_translation ADD CONSTRAINT wiki_translation_id_wiki_id FOREIGN KEY (id) REFERENCES wiki(id) ON UPDATE CASCADE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE;

The error is:

SQLSTATE[42830]: Invalid foreign key: 7 FEHLER: in Tabelle »wiki_translation«, auf die verwiesen wird, gibt es keinen Unique Constraint, der auf die angegebenen Schlüssel passt. Failing Query: ALTER TABLE wiki_translation_version ADD CONSTRAINT wiki_translation_version_id_wiki_translation_id FOREIGN KEY (id) REFERENCES wiki_translation(id) ON UPDATE CASCADE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE

It is in german but it means something like: there is no unique constraint in table 'wiki_translation' matching the given key.

Michael



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

hmm...I am not really sure what is wrong with that SQL on pgsql. Any ideas?

Comment by Michael Piecko [ 24/Oct/09 ]

Ok, i spend some days on this, but i don't know if this is the real issue or how to solve it:

The table wiki_translation has a two column primary key (constraint) with (id, lang), so all ALTER commands which references this table (1st and 2nd in my post above) need to reference BOTH of them, because just (id) is not unique in the translation table (that makes sense). So what i did is to change the first two ALTER commands (which references the translation table) to:

... FOREIGN KEY (id, lang) REFERENCES wiki_translation(id, lang) ...

This works on pgsql. But i don't know why MySQL obviously has no problems with it ... :o(

Michael

Comment by Jonathan H. Wage [ 27/Oct/09 ]

Ok I think I know the issue. I will try and commit a patch for it this week.

Comment by Michael Piecko [ 27/Oct/09 ]

Great to hear that. I'll be there to test it ;o)

Thx a lot,
Michael

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

Ok I was wrong. This can't be fixed. I gave it a good solid try but I can't fix it without completely breaking BC. Users would not be able to upgrade easily and it is a huge change. It will have to remain broken until someone can figure out something that works and is BC.

Comment by Michael Piecko [ 02/Nov/09 ]

Well, that's the way life goes ... :o(
But it should be mentioned, that nesting these behaviours WORKS on mysql, but in this case not on pgsql.

Thanks a lot,
Michael

Comment by thibault duplessis [ 09/Dec/09 ]

Hello

This really shall appear on the documentation.

Right here : http://www.doctrine-project.org/documentation/manual/1_2/en/behaviors#nesting-behaviors

The documentation suggests it is possible, but it's not.

Comment by Chris Miller [ 13/Dec/09 ]

So will this be fixed in 2.0?

Versioning with i18n is a MUST HAVE for a project I'm currently working on and MySQL isn't an option.





[DC-132] LOB mode not used for BLOB fields that are specified as a file handle Created: 23/Oct/09  Updated: 24/Oct/09  Resolved: 24/Oct/09

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

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

Attachments: File doctrine-1.2-work-around-for-blob-field-type.diff    

 Description   

PDO provides us with the (highly desirable) possibility of providing the contents for a blob file through a filehandle resource, so the data can be read directly from a file or another stream source. When retrieving blob data from the database, I already get such file handle back. However, when creating of updating a record with a blob field using a filehandle, this fails. It fails because of two issues:

  • Doctrine_Validator::isValidType() rejects the resource handle, because blob fields are only checked using is_string().
  • $sth->execute($params) is used for executing a query after preparing it. The $params are provided straight away to the statement handle, without differentiating between field types by means of explicit bindings. An explicit binding with Doctrine::PARAM_PDO would be needed to allow for field data upload using a filehandle.

I have already been going over the code and I could not find a very good spot for handling this. What functionally should happen is that:

  • a blob field
  • for which a stream resource is set
  • should not be rejected as a valid blob type field and
  • should be bound as a param to the prepared insert/update query
  • using the data type Doctrine::PARAM_LOB

In the attached patch, I have updated the code in a way that makes this feature work. What I did feels like a hack, but I couldn't find a good way to implement this cleanly. The type of field that we are handling (blob or not?), the data that we are handling (resource or not?) and the spot where we can use bindParam() are not really tightly interconnected (or maybe they are and I overlooked it).






[DC-130] Doctrine::generateModelsFromDb fails on foreign key relationships with certain table names on Postgresql Created: 21/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.1.4, 1.2.0-ALPHA2
Fix Version/s: 1.0.13, 1.1.5, 1.2.0-BETA1

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

Ubuntu 9.04 postgresql-8.3



 Description   

Create the following tables:

CREATE TABLE "user" (
id serial PRIMARY KEY,
name varchar(30) NOT NULL
);

CREATE TABLE "group" (
id serial PRIMARY KEY,
name varchar(30) NOT NULL
);

CREATE TABLE "user_x_group" (
id serial PRIMARY KEY,
user_id int NOT NULL REFERENCES "user" ( id ),
group_id int NOT NULL REFERENCES "group" ( id ),
UNIQUE ( user_id, group_id )
);

If you try to run Doctrine::generateModelsFromDb() it will crash with
Uncaught exception 'Doctrine_Import_Builder_Exception' with message 'Missing class name.'

This is caused by the fact that the table 'user' (and 'group' also, for that matter) is escaped with quotes when
passed through pg_get_constraintdef, because 'user' (and 'group') is a reserved word.

A solution would be to modifiy the regexp in Doctrine_Import_Pgsql::listTableRelations so that it strips the quote characters
from identifiers.






[DC-128] search is using default connection for query not the indexed table's connection Created: 21/Oct/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Searchable
Affects Version/s: 1.1.4
Fix Version/s: 1.2.0-BETA1

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

Doctrine 1.1 revision 6546


Attachments: Text File d_search.patch    

 Description   

I'm using two databases with two connections, one of these only in one component of the project.

I used Doctrine_Manager::bindComponent to set the connection for the tables of the second database, and left the main database's connection as default.

The bug happens when I'm using search() in a searchable table of the second database. Doctrine_Search::search function uses the default connection when queries the index table, instead of the connection bound to the searchable table.

I attached a patch, which works for me.






[DC-127] Allow a class prefix to be specified when calling Doctrine_Core::loadModels() Created: 20/Oct/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

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

Type: Improvement Priority: Major
Reporter: Glen Ainscow Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

Doctrine allows you to generate class names such as Blog_Model_Post in Post.php, but Doctrine::loadModels() is not able to load these models conservatively, as the class name and file name differ.

I suggest adding a third parameter to Doctrine_Core::loadModels() to specify a class prefix, for example:

Doctrine_Core::loadModels('/modules/blog/models', Doctrine_Core::MODEL_LOADING_CONSERVATIVE, 'Blog_Model_');

Code changes (I think) would be something like this:

public static function loadModels($directory, $modelLoading = null, $classPrefix = null)
{
...
	$className = $e[0];
	
	if ($classPrefix) {
		$className = $classPrefix . $className;
	}
...
}

Since the argument is optional, this change shouldn't break any existing code.

NB: This is not PEAR-style file/class naming.






[DC-116] getParent() works as getRoot() in NestedSet behavior Created: 17/Oct/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Behaviors
Affects Version/s: 1.1.4
Fix Version/s: 1.0.13, 1.1.5, 1.2.0-BETA1

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

Windows
PHP 5.3.0



 Description   

This is current version of getParent()

public function getParent()
    {
        $baseAlias = $this->_tree->getBaseAlias();
        $q = $this->_tree->getBaseQuery();
        $q->addWhere("$baseAlias.lft < ? AND $baseAlias.rgt > ?", array($this->getLeftValue(), $this->getRightValue()))
                ->addOrderBy("$baseAlias.rgt asc");
        $q = $this->_tree->returnQueryWithRootId($q, $this->getRootValue());
        $result = $q->execute();
        if (count($result) <= 0) {
            return false;
        }
               
        if ($result instanceof Doctrine_Collection) {
            $parent = $result->getFirst();
        } else if (is_array($result)) {
            $parent = array_shift($result);
        }
        
        return $parent;
    }

As you can see, this method does not have level limit in where clause. If tree have more than 2 levels in depth, method will return root node of the tree, not parent.

My fix is use level limit:

public function getParent()
    {
        $baseAlias = $this->_tree->getBaseAlias();
        $q = $this->_tree->getBaseQuery();
        $q->addWhere("$baseAlias.lft < ? AND $baseAlias.rgt > ?", array($this->getLeftValue(), $this->getRightValue()))
                ->addOrderBy("$baseAlias.rgt asc");
        $q->addWhere("$baseAlias.level >= ?", $this->record['level'] - 1);
        $q = $this->_tree->returnQueryWithRootId($q, $this->getRootValue());
        $result = $q->execute();
        if (count($result) <= 0) {
            return false;
        }
               
        if ($result instanceof Doctrine_Collection) {
            $parent = $result->getFirst();
        } else if (is_array($result)) {
            $parent = array_shift($result);
        }
        
        return $parent;
    }

PS. Sorry for my english.






[DC-115] Doctrine_Cli and Doctrine_Task: further improvements to creation and registration of custom tasks Created: 17/Oct/09  Updated: 23/Oct/09  Resolved: 23/Oct/09

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

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

Darwin, PHP 5.3, MacBook


Attachments: File doctrinecli_and_doctrinetask_refactorings_and_tests.diff    

 Description   

Having worked with - and experienced the 'inconveniences' of - my previous changes (see r6475), I have made further improvements to Doctrine_Cli, and a small change to Doctrine_Task, and have achieved the following.

  • Creating and working with custom tasks is now even easier.
  • Doctrine_Cli is even more powerful since it is now that much easier to extend.
  • Doctrine_Cli is more testable - though there's still room for improvement.

The enclosed patch was created against 1.2 r6535. I have merged changes committed since r6475 - Jon's changes in r6484.

Further details:

Doctrine tasks are always included and 'registered' on startup. By default, loaded custom tasks are then registered.

Custom tasks need only extend Doctrine_Task - there are no special naming conventions to follow.

Automatic loading of custom tasks can be disabled by setting the new "autoregister_custom_tasks" config option to FALSE (TRUE is the default).

The following code includes and registers Doctrine core Tasks, and then registers loaded custom tasks.

$cli = new Doctrine_Cli();
$cli->run($_SERVER['argv']);

The following code includes and registers only Doctrine core Tasks.

$oCli = new Doctrine_Cli(array('autoregister_custom_tasks' => false));
$oCli->run($_SERVER['argv']);

The following code includes and registers Doctrine core Tasks, and then registers a custom task loaded after the CLI was instantiated.

$oCli = new Doctrine_Cli();

require_once(dirname(_FILE_) . '/TestTask02.php');

//Either...:
$oCli->registerTaskClass('Doctrine_Cli_TestCase_TestTask02');
//...Or:
$oCli->registerIncludedTaskClasses();

$oCli->run($_SERVER['argv']);

(These code examples can be found in /tests/CliTestCase.)

Responsibility for naming tasks lies with the tasks themselves. Tasks will still receive a name derived from the fully-qualified (i.e. including namespaces) name of their class, but it is now possible to specify the name at design time - you might want to do this if the default task name would be very long or undesirable for some reason.

For example:

namespace fully\qualified;

class CustomTaskName extends \Doctrine_Task {

//This task would otherwise be registered as "fully-qualified-custom-task-name"
public $taskName = 'custom-task-name';

public function execute () {}
}

A CLI can now be instructed to rethrow exceptions. This is very useful if you're running a batch of tasks in a single script and you need processing to stop if one of them fails.

Simply set the new "rethrow_exceptions" config option to TRUE to enable this behaviour - the default is FALSE.

For example:

$oCli = new Doctrine_Cli(array(
'autoregister_custom_tasks' => false,
'rethrow_exceptions' => true,
));

$oCli->run($_SERVER['argv']);

I think there are still one or two things I'd like to look at, but I wanted to get the bulk of the work in so I don't hold you up.

Oh, and I'd like to apologise for having moved everything around. I wouldn't normally, but in trying to make sense of things, I found it necessary.






[DC-114] calculateQueryCacheHash / calculateResultCacheHash with pendingJoinConditions Created: 16/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Behaviors
Affects Version/s: 1.1.4
Fix Version/s: 1.2.0-BETA1

Type: Improvement Priority: Minor
Reporter: Florian Pfeiffer Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: File abstract.diff    

 Description   

I've modified SoftDelete so that the preDqlSelect part is only applied when a specific param in the Manager is set. Currently this works like expected, but I've discovered a small problem, when I've enabled the QueryCache:

Since SoftDelete adds the "where is_deleted=0" as a pendingJoinCondition it isn't taken into account by the calculateXXXCacheHash function

I've made a small patch to Query/Abstract.php that takes the pendingCondition into account






[DC-110] Doctrine_Export_Mysql does not quote tableName in createIndexSql() Created: 15/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.1.4
Fix Version/s: 1.0.13, 1.1.5, 1.2.0-BETA1

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

CentOs with ZendServer and PHP 5.2.9, Doctrine 1.1.4


Attachments: Text File doctrine-mysql-export.patch    

 Description   

Very simple issue, seems that has been forgotten in this case. One of us in the developer team had the great idea to name a table "group". So we need quoting And adding a index on this table within a migration was not possible because the table name doesn't get quoted when adding an index..

So I added the tiny patch necessary to correct this.. I know it's not impressing but it's a fix Maybe it gets in the maintenance release 1.1.5 before the 2.0 stable comes out (if there is anything more in the 1.1.* line)..






[DC-103] doctrine 1.0 not getting table correctly - huge bug - not usable Created: 13/Oct/09  Updated: 30/Oct/09  Resolved: 30/Oct/09

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

Type: Bug Priority: Critical
Reporter: Nopcea Flavius Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 1
Labels: None
Environment:

WIN XP



 Description   

In the method coreSetRelated from Record.php for 1-1 relation the table is not obtained correctly!

if ($value !== self::$_null)

{ $relatedTable = $value->getTable(); $foreignFieldName = $relatedTable->getFieldName($rel->getForeign()); }

instead of

$relatedTable = $value->getTable();

you should put

$relatedTable = $rel->getTable();

This is a huge bug that can be fixed very easily so please fix is asap!

I can not deploy my project until this is fixed!

Thanks a lot!

I do not know if other versions are affected! I use symfony 1.2.9! Should I make a ticket also for Symfony!

You do a great job with doctrine! Great project! I really like it



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

This sounds like a bug in your own code. $value should be an instance of Doctrine_Record and it is not. Make sure you're code is not passing an array or invalid value through to coreSetRelated(). If you're using symfony, a common cause of this is that you have an embedded form that has the same name as your relationship. This can cause issues currently.

Comment by Nopcea Flavius [ 14/Oct/09 ]

Hi!

I am using symfony but I have a regular form! Not an embedded one!

I have like this:

$form->getObject()->setAuthorId($authorId);

and when I do a $form->save I get an error in that method when dealing with the author!

If I do a var_dump($value) it will not be an object but a string variable!

$relatedTable = $value->getTable();

I worked with previous versions of symfony/doctrine but once I upgraded to 1.2.9 it doesn't work anymore!

To me it seems that in the saving process Doctrine is not getting the correct $value object!

Comment by Nopcea Flavius [ 14/Oct/09 ]

Hi!

I am using symfony but I have a regular form! Not an embedded one!

I have like this:

$form->getObject()->setAuthorId($authorId);

and when I do a $form->save I get an error in that method when dealing with the author!

If I do a var_dump($value) it will not be an object but a string variable!

$relatedTable = $value->getTable();

I worked with previous versions of symfony/doctrine but once I upgraded to 1.2.9 it doesn't work anymore!

To me it seems that in the saving process Doctrine is not getting the correct $value object!

Comment by Olivier [ 23/Oct/09 ]

Quite same problem here.

My code worked fine with Symfony 1.2.7, but I have the same fatal error since 1.2.8. If I change $value to $rel, everything works fine.

I'm using embedded forms with Doctrine and I have another way to solve it :

  • With this, I've got the issue :
    $this->embedForm('contact_physique', $contactForm);
  • But no anymore with this :
    $this->embedForm('ContactPhysique', $contactForm);

contact_physique is a relationship in my schema.

I do not know if that "new behavior" comes from Doctrine or Symfony, but it may help with Nopcea Flavius' problem.

Regards





[DC-96] Add support for the SET datatype Created: 09/Oct/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

Type: New Feature Priority: Major
Reporter: Lukas Kahwe Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

Similar to the ENUM datatype, MySQL also invented the SET datatype. Emulation should be easily doable just like its currently done for ENUM.
http://dev.mysql.com/tech-resources/articles/mysql-set-datatype.html






[DC-93] Calling refreshRelated causes hasOne records to be created in error Created: 08/Oct/09  Updated: 30/Oct/09  Resolved: 30/Oct/09

Status: Closed
Project: Doctrine 1
Component/s: Relations
Affects Version/s: 1.1.4
Fix Version/s: 1.0.13, 1.1.5, 1.2.0-BETA1

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

Linux


Attachments: GZip Archive Doctrine-1.1.4-Sandbox.tar.gz    

 Description   

Calling save() on a record, then refreshRelated(), then save() again will cause hasOne rows to be generated in error. I've attached a Doctrine sandbox with everything you need to reproduce it. Below is a summary.

schema.yml

schema.yml
 
---
Staff:
  columns:
    username: string(50)
    password: string(255)
    active:
      type: boolean
      default: true
  indexes:
    user_pass_active_idx:
      fields: [username, password, active]


Tickets:
  columns:
    mask:
      unique: true
      type: string(10)
    staff_id: integer(9)
  relations:
    Staff:
      local: staff_id
      foreign: id
Test.php
 
<?php
$ticket = new Tickets();
$ticket->save();
$ticket->refreshRelated();
$ticket->save();

Queries that were run:

root@localhost on doctrine11sandbox
START TRANSACTION
INSERT INTO tickets (id, mask, staff_id) VALUES (NULL, NULL, NULL)
COMMIT
START TRANSACTION
*INSERT INTO staff (active) VALUES ('1')*
UPDATE tickets SET staff_id = '2' WHERE id = '2'
COMMIT


 Comments   
Comment by Justin Mazzi [ 08/Oct/09 ]

This seems to be enough to trigger it:

<?php
$ticket = new Tickets();
$ticket->refreshRelated();
$ticket->save();
Comment by Justin Mazzi [ 13/Oct/09 ]

I've tracked this down to fetchRelatedFor. This is the function creating the record:

LocalKey.php
<?php
/*
 *  $Id: LocalKey.php 5798 2009-06-02 15:10:46Z piccoloprincipe $
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 * This software consists of voluntary contributions made by many individuals
 * and is licensed under the LGPL. For more information, see
 * <http://www.phpdoctrine.org>.
 */

/**
 * Doctrine_Relation_LocalKey
 * This class represents a local key relation
 *
 * @package     Doctrine
 * @subpackage  Relation
 * @author      Konsta Vesterinen <kvesteri@cc.hut.fi>
 * @license     http://www.opensource.org/licenses/lgpl-license.php LGPL
 * @link        www.phpdoctrine.org
 * @since       1.0
 * @version     $Revision: 5798 $
 */
class Doctrine_Relation_LocalKey extends Doctrine_Relation
{
    /**
     * fetchRelatedFor
     *
     * fetches a component related to given record
     *
     * @param Doctrine_Record $record
     * @return Doctrine_Record|Doctrine_Collection
     */
    public function fetchRelatedFor(Doctrine_Record $record)
    {
        $localFieldName = $record->getTable()->getFieldName($this->definition['local']);
        $id = $record->get($localFieldName);

        if (is_null($id) || ! $this->definition['table']->getAttribute(Doctrine::ATTR_LOAD_REFERENCES)) {
            /* HERE */
            $related = $this->getTable()->create();





[DC-87] Import / export does not take into account the connection to the database Created: 07/Oct/09  Updated: 30/Oct/09  Resolved: 30/Oct/09

Status: Closed
Project: Doctrine 1
Component/s: Connection, Import/Export, Schema Files
Affects Version/s: 1.1.4
Fix Version/s: 1.2.0-BETA1

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

Environment does not matter, the problem occurs in the Doctrine code. he problem occurs in any environment.



 Description   

The mechanism of imports and exports does not include connection to the database. This creates many problems when we have multiple connections to the database and want to use a command to generate. (generateYamlFromDb or generateYamlFromModels or generateModelsFromDb or generateModelsFromYaml and other related methods)

Possible solution:

The file Doctrine/Import.php between lines 384 and 385 insert:
$definition['connection'] = $connection->getName();
$definition['connectionClassName'] = $definition['className'];

The file Doctrine/Export/Schema.php between lines 71 and 72 insert line:
$table['connection'] = $recordTable->getConnection()->getName();






[DC-74] Condition of STATE_PROXY should be checked dynamically, not as a static state value Created: 30/Sep/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

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

Type: Bug Priority: Major
Reporter: Jacek Dębowczyk Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: File DC74-1.2.diff     Text File DC74.patch     File DC74TestCase.php    

 Description   

This issue is continuation of issue #2488 from Trac. I have prepared Test case showing that the problem is seriously. Below original content.

A record gets STATE_PROXY state at hydration when its properties are not fully loaded. Here is a condition (placed in Doctrine_Record::hydrate()):

if ( ! $this->isModified() && count($this->_values) < $this->_table->getColumnCount()) {
   $this->_state = self::STATE_PROXY;
}

But at first setting a column value (whatever if the column value was loaded or not), the record gets STATE_DIRTY and "forgets" its proxy state.

In effect a call to any not loaded column of the record causes returning null value. It should, of course, load remaining column values and change record state from STATE_PROXY to STATE_DIRTY. It doesn't load because current record state is already STATE_DIRTY.

I'm attaching a patch, which fixes Doctrine_Record::load() in the described situation.

In my opinion usage of STATE_PROXY must be rethinked. STATE_PROXY can mean:
1. STATE_CLEAN + not fully loaded columns (proxy)
2. STATE_DIRTY + not fully loaded columns (proxy)

Currently it only points the first situation so there is not way to identify the second situation (and it is silently ignored).



 Comments   
Comment by Jacek Dębowczyk [ 30/Sep/09 ]

I'm including a patch.

I think that the patch needs a little explanation. To solve the problem I see 2 solutions:
1. create new state, eg. STATE_PROXY_MODIFIED being activated when a proxy record gets modified
2. transform existing conditions to check proxy state dynamically using new Doctrine_Record::isInProxyState() method

I chosen the second as a less invasive way. A record is in proxy state when it has any not loaded properties - this must be found out by the method. But... currently there is no way to find this. Doctrine_Null object in $record->_data means that property is not loaded yet OR it has null value.
In the patch I divided real null value (simply stored as null in _data) from unknown (not loaded) value (stored as Doctrine_Null).

Comment by Jonathan H. Wage [ 13/Oct/09 ]

When I tried this patch, it broke the test suite. Can you try your patch again?

Comment by Jacek Dębowczyk [ 20/Oct/09 ]

It breaks 2 test cases.

The first is Doctrine_Ticket_1449_TestCase. I have appended following code to prepareData() in the test:

        $document->Attachments->getFirst()->getTable()->clear();
        $document->getTable()->clear();

and added "a.document_id" column to select:

        $document = Doctrine_Query::create()
            ->select('d.id, d.name, a.id, a.document_id')

and the test passes. IMHO problem is in the test, what I noticed in DC-73.

The second is Doctrine_Relation_OrderBy_TestCase. Currently there are identical queries asserted for lazy load $user->ChildrenUsers and $user->ParentUser. IMHO second query in the test (line 93) is wrong. Could you check this?

Comment by Jacek Dębowczyk [ 20/Oct/09 ]

I'm including the patch adapted to Doctrine-1.2.





[DC-73] TestCase framework normally uses identityMap for records created in prepareData() what can cause side effects Created: 30/Sep/09  Updated: 30/Oct/09  Resolved: 30/Oct/09

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

Type: Bug Priority: Critical
Reporter: Jacek Dębowczyk Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: Text File DC73-full.patch     File DC73TestCase.php    

 Description   

All new records are stored in the identityMap during insertion. This default behavior takes place also while executing test cases.

In other words every record created in the prepareData() method gets to the identityMap. Afterwards, in a test method, it is silently retrived from identityMap instead of (expected!) quering from sqlite.

IMHO a testing environment should be as pure as possible and no such side effects are acceptable.

I'm including a test case and patch for Doctrine_UnitTestCase. After putting the patch, I have found that 2 test cases causes fail: 1449 and 736. In the first test IMHO there is a problem in a content test - I'm including appropriate fix.
It seems that the second test, in fact, have never been passing. I think that positive result was caused by the side effect of identityMap.



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

This breaks the 1.2 test suite. Can you retry your patch?

Comment by Jacek Dębowczyk [ 20/Oct/09 ]

Yes, the patch breaks 2 test cases: 1449 and 736.
I explained it above in the ticket description.

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

Does your patch fix those 2 failing test cases now?

Comment by Jacek Dębowczyk [ 20/Oct/09 ]

Ok, now I'm including a patch that also fixes both test cases and causes all 1.2 tests passes.





[DC-69] Linking between one to one relations with synchronizeWithArray fails Created: 28/Sep/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Relations
Affects Version/s: 1.0.12, 1.1.4, 1.2.0-ALPHA1
Fix Version/s: 1.2.0-BETA1

Type: Bug Priority: Blocker
Reporter: Marcus Häußler Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

tested on
MySQL
Doctrine Version 1.0.11 Revision: 6380
Doctrine Version 1.1.3 Revision: 6380
Doctrine Version 1.1.4 Revision: 6409
Doctrine Version 1.2



 Description   

Linking between one to one relations with synchronizeWithArray() ends up in an error message.

Example:
Group has one User
User has one Group

When I have a group-object and do the following:

$group->synchronizeWithArray(array(
	'User' => array(1)
));
$group->save();

I get the message: "Fatal error: Call to a member function identifier() on a non-object in [..]lib/Doctrine/Record.php on line 2327"

Apparantly $this->_references[$alias] should be an collection, but in an one to one relation it is a record (which makes sense in my opinion).



 Comments   
Comment by Marcus Häußler [ 01/Oct/09 ]

I just realized that the whole linking process in one to one relations is not working.

A simple

$group->link('User', 1);

ends up in <b>Fatal error</b>: Uncaught exception 'Doctrine_Exception' with message 'Add is not supported for User' in [..]/Doctrine/Access.php:201

Because in Doctrine_Record the add-method is completely missing
I hope it's just more or less a copy/past of Doctrine_Collection->add()

Comment by Marcus Häußler [ 09/Oct/09 ]

I have build a fix that works for me, but I did not tested it fully.

Index: library/Doctrine/Doctrine/Record.php
===================================================================
--- library/Doctrine/Doctrine/Record.php        (Revision 6462)
+++ library/Doctrine/Doctrine/Record.php        (Arbeitskopie)
@@ -2323,13 +2323,23 @@
         }

         if (isset($this->_references[$alias])) {
-            foreach ($this->_references[$alias] as $k => $record) {
-                if (in_array(current($record->identifier()), $ids) || empty($ids)) {
-                    $this->_references[$alias]->remove($k);
-                }
-            }

-            $this->_references[$alias]->takeSnapshot();
+                       /*
+                        * Fix for One To One Relations
+                        */
+               if ($this->_references[$alias] instanceof Doctrine_Record) {
+                       if (in_array($this->_references[$alias]->identifier(), $ids) || empty($ids)) {
+                               unset($this->_references[$alias]);
+                       }
+               } else {
+                       foreach ($this->_references[$alias] as $k => $record) {
+                               if (in_array(current($record->identifier()), $ids) || empty($ids)) {
+                                       $this->_references[$alias]->remove($k);
+                               }
+                       }
+                   $this->_references[$alias]->takeSnapshot();
+               }
+
         }

         if ( ! $this->exists() || $now === false) {
@@ -2406,7 +2416,14 @@
                 ->execute();

             foreach ($records as $record) {
-                $this->$alias->add($record);
+               /*
+                * Fix for One To One Relations
+                */
+               if ($this->$alias instanceof Doctrine_Record) {
+                       $this->$alias = $record;
+               } else {
+                       $this->$alias->add($record);
+               }
             }




[DC-65] Add documentation for Doctrine::ATTR_HYDRATE_OVERWRITE Created: 25/Sep/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

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

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


 Description   

Maybe this sould be added somewhere in docs (since there's nothing about that in 1.1's)

$manager->setAttribute(Doctrine::ATTR_HYDRATE_OVERWRITE, false);





[DC-55] Add documentation for record filters Created: 24/Sep/09  Updated: 03/Nov/09  Resolved: 03/Nov/09

Status: Resolved
Project: Doctrine 1
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 1.2.0-BETA1

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


 Description   

There's nothing in the 1.0 documentation about Doctrine_Record_Filter. Would be nice because it's a handy feature!






[DC-39] Linking between one to many relations with synchronizeWithArray fails Created: 18/Sep/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Relations
Affects Version/s: 1.0.12, 1.1.4, 1.2.0-ALPHA1
Fix Version/s: 1.2.0-BETA1

Type: Bug Priority: Blocker
Reporter: Marcus Häußler Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

tested on
PHP Version 5.2.6-3ubuntu4.2, PHP Version 5.3
MySQL, PgSQL
Doctrine Version 1.0.11 Revision: 6380
Doctrine Version 1.1.3 Revision: 6380
Doctrine Version 1.1.4 Revision: 6409
Doctrine Version 1.2


Attachments: File DC39TestCase.php     File example.php    

 Description   

Linking between one to many relations with synchronizeWithArray() has a strange behavior.

Example (fully example is in the attachment):
Group has many Users
User has one Group

When I have a group-object (id 2) and do the following:

$group->synchronizeWithArray(array(
	'Users' => array(1,2)
));
$group->save();

on the first execute of the script the users with id 1 and 2 are linked to group 2 (with foreign key = group_id in user table) -> right
on the second execute of the script the users with id 1 and 2 are linked to null -> failure
on the third execute of the script the users with id 1 and 2 are linked to group 2 -> right
on the fourth execute of the script the users with id 1 and 2 are linked to null -> failure
and so on

I tried to find the error on my self, but had no luck.
That's what I have found:
On every script-execution the relations to group 2 are first nulled.
If they were allready null für user 1 and 2, the relations are build with an update -> right!; but when this two users had allready this relation they are only nulled and no update is processed.
Thats why there is this strange toggling on the foreign key on every script execution.

Maybe it has something to do with the record_state which is clean, when the relations are allready set in the DB -> no update is executed, but the nulling of all foreign key linked to group 2.



 Comments   
Comment by Marcus Häußler [ 28/Sep/09 ]

I changed the code on record.php near line 1923 to

 
                if (is_array($value)) {
                    if (isset($value[0]) && ! is_array($value[0])) {
                        $this->unlink($key, array(), true); // parameter set to true
                        foreach ($value as $id) {
                            $this->link($key, $id, true); // parameter set to true
                        }
                    } else {
                        $this->$key->synchronizeWithArray($value);
                    }
                }

With this changed parameters the described bug does not appear, cause the whole state-checking (in UnitOfWork->saveGraph()) is not used and the querys are submitted emidiatly.

Of course this can not be the way, but I hope it helps you a bit to find the error and others who need the synchronizeWithArray method working now.

Comment by Jonathan H. Wage [ 06/Oct/09 ]

Have you tried producing a test case for this? When I tested it I was not able to produce the same behavior in Doctrine standalone. Does this happen in your project or did you try outside of your project with just Doctrine?

Comment by Marcus Häußler [ 07/Oct/09 ]

I tested this with doctrine as a standalone.

Have you looked at the database entries with an external query-browser or have you just looked at the objects?
The doctrine_records/collections are build right while the database entries can act with the described behavior.

I will try to build a testcase but tell me wether you looked in the database to recognize the behavior.

Comment by Marcus Häußler [ 07/Oct/09 ]

Testcase uploaded.





Generated at Thu Oct 02 16:47:22 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.