[DC-1065] http://www.doctrine-project.org/jira/browse/DC-98 Created: 17/Jul/14  Updated: 17/Jul/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: BizLogic Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: bug, generation, model, patch
Environment:

Linux, PHP


Attachments: File Builder.php    
Issue Links:
Duplicate
duplicates DC-98 Generated base class file names get e... Resolved

 Description   

Doctrine 1.2.4 does not respect the variable baseClassPrefixFiles when generating models.
Generated base files will always have the prefix specified in the baseClassPrefix variable.

Example PHP Code:
		Doctrine_Core::generateModelsFromDb(
			BASEDIR.'/application/models',
			array('doctrine'),
			array(	
				'generateTableClasses'	=> true, 
				'baseClassPrefix'		=> 'Generated_',
				'baseClassesDirectory'	=> 'Generated',
				'baseClassPrefixFiles'	=> false,
				'classPrefixFiles'		=> false
			)
		);

A patched version of ./Doctrine/Import/Builder.php is attached



 Comments   
Comment by BizLogic [ 17/Jul/14 ]

http://www.doctrine-project.org/jira/browse/DC-98?focusedCommentId=23753&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-23753





[DC-1061] ORACLE CHARSET DOCUMENTATION Created: 10/Jul/10  Updated: 28/Dec/13

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

Type: Improvement Priority: Major
Reporter: fernando guerrero Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ORACLE db SYMFONY



 Description   

Openning an Oracle Database with Doctrine and Symfony doesn't support by default utf8 charset.

To support it, it is necessary to specify charset=AL32UTF8 in the dsn of the database in config/databases.yml. Analogous to the example shown at
http://groups.google.com/group/doctrine-user/browse_thread/thread/d0d22145d8bdc83
however we have been able to use it fully only with the oracle driver (instead of oci), for example:

oracle:dbname=//192.168.2.9:1521/nomina_dev;charset=AL32UTF8

Documentation by Alexia Velásquez (alexia.velasquez@hotmail.es, Vladimir Tàmara (vtamara@pasosdeJesus.org) and Fernando Guerrero



 Comments   
Comment by Steve Müller [ 26/Nov/13 ]

I know this ticket is very old. But there is an option to set the charset for OCI8. See:

http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#pdo-oci-oci8

Comment by Steve Müller [ 28/Dec/13 ]

This is a legacy ticket related to Doctrine 1.





[DC-1060] Datetime Fomatting not working on findId in DB2 Platform Created: 24/Sep/13  Updated: 24/Sep/13

Status: Open
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.3
Fix Version/s: 1.2.3

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

In DB2/Symfony2


Attachments: PNG File Screen Shot 2013-09-24 at 3.55.44 PM.png     PNG File Screen Shot 2013-09-24 at 3.56.13 PM.png    

 Description   

We had to put this fix to check for DateTimeTz in SimpleObjectHydartor to make it work for DB2. Same code works for mysql. Is it possible to put a fix as part of release of next Doctrine so we need not update vendor code locally.
if (isset($cache[$column]['field'])) {
$type = Type::getType($cache[$column]['class']->fieldMappings[$cache[$column]['name']]['type']);
if ($type == 'DateTimeTz')

{ $value = substr($value, 0, 19); }

$value = $type->convertToPHPValue($value, $this->_platform);
}

The error happens when we do a find($id) in
$ep = $em->getRepository('some name')->find($id);






[DC-1057] Inserts instead of updates for related objects Created: 20/Jul/12  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Grzegorz Godlewski Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

linux, apache2, php 5.3



 Description   

Ok, so the object relations go like this:

  • Comparison
    • [1:N] Product (FK:comparison_id)
      • [1:N] Rules (FK:product_id, FK:option_id)
      • [1:N] Parameters (FK:product_id)
        • [1:N] Options (FK:parameter_id)

The testing code looks like following:

== CODE START ==

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
$comp = new Application_Model_Comparison();

/* Filling $comp with data */

for ($i = 0; $i < 10; $i++) {

    $product = new Application_Model_Product();

    // Options referenced in Rules
    $options = array();

    for ($j = 0; $j < 10; $j++) {

        $param = new Application_Model_Parameter();

        for ($k = 0; $k < 10; $k++) {

            $option = new Application_Model_Option();

            $param->Options->add($option);

            // Register a single option for this parameter
            if (!isset($options[$j])) {
                $options[$j] = $option;
            }
        }

        $product->Parameters->add($param);
    }

    for ($j = 0; $j < 10; $j++) {
        $rule = new Application_Model_Rule();

        $rule->Option = $options[$j];
        $product->Rules->add($rule);
    }

    $comp->Products->add($product);
}

/**
 * The first save() goes nicely, all objects
 * are created (INSERTed)
 */ 

$comp->save();

// Remove every second product
$pCount = $comp->Products->count();

for ($i = 0; $i < $pCount; $i += 2) {
    $comp->Products->remove($i);
}

/**
 * Fails while trying to save
 *
 * Comparison->Product->Parameter->Option
 * INSERT ... `parameter_id` cannot be NULL
 *
 * Comparison->Product->Rule
 * INSERT ... `product_id` cannot be NULL
 */

$comp->save();

== CODE END ==

The first save() cleans up the relation information in the graph. All child objects are INSERTED instead of UPDATE.






[DC-1056] Doctrine is not compatible with PHP 5.4 due to change in serialize() behaviour. Created: 04/Jun/12  Updated: 06/Oct/13

Status: Open
Project: Doctrine 1
Component/s: Record, Relations
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Marcin Gil Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 2
Labels: None
Environment:

PHP 5.4+


Attachments: Text File Record.php.patch    

 Description   

In PHP 5.4 there is a change in the way the object references are serialized:

Quote:
"Support for object references in recursive serialize() calls
Prior to PHP 5.4, object references where not saved in recursive serialize calls."

This minor change, breaks down serialization of collections when column of type "array" is present - double serialization occurs.
I'm attaching a patch fixing the issue.



 Comments   
Comment by Colin Darie [ 15/Oct/12 ]

I confirm for possible future readers: this patch works perfectly well. (cf github for several forks of doctrine with other bugfixes).

Comment by steven [ 27/Jan/13 ]

Hi all, does somebody knows where can I get a copy of the Doctrine 1.2.4 version but running on php 5.4?
Thise version you're talking about

Thanks

Comment by Marcin Gil [ 28/Jan/13 ]

I sent you URL to our private svn repo.

Comment by steven [ 28/Jan/13 ]

Thanks, you've saved mi life

Comment by Marcin Gil [ 06/Oct/13 ]

New, better patch.

Comment by Marcin Gil [ 06/Oct/13 ]

Hi, I have uploaded a better patch which resolved one more issue.

Comment by Christophe Coevoet [ 06/Oct/13 ]

Please use a pull request on github to submit a patch





[DC-1055] Bug in select query when executed against postgreSQL Created: 25/May/12  Updated: 25/May/12

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

Type: Bug Priority: Major
Reporter: Damian Bergantinnos Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

symfony-1.4.17 php 5.3.5 apache 2.2.17 WIndows xp/7 PostgreSQL 9.1.2


Attachments: File schema.rar    

 Description   

In the attached Squema run this query against postgreSQL.
(it runs ok In mysql)

$lang = 'en';
$session = 1;
$q = Doctrine_Query::create()
->from('Sys_Trace t')
->leftJoin('t.Sys_Session s')
->leftJoin('t.Translation tr WITH tr.lang = ?', array($lang))
->leftJoin('t.Sys_Oper so')
->leftJoin('so.Translation tr2 WITH tr2.lang = ?', array($lang))
>where('t.session_id = ?', array($session));

SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for integer: "en"






[DC-1054]  SQLSTATE[42S22]: Column not found: 1054 Unknown column 'b.title' in 'field list' Created: 31/Mar/12  Updated: 31/Mar/12

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

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

window vista



 Description   

this is the my table creation .

CREATE TABLE billboard(id BIGINT AUTO_INCREMENT,title VARCHAR (255),country_id BIGINT,zone_id BIGINT,place VARCHAR(255),occassion VARCHAR(255),itinerary VARCHAR(255),created_at DATETIME NOT NULL,description TEXT NOT NULL,PRIMARY KEY(id)) ENGINE=INNODB;

public static function getInstance()

{ return Doctrine_Core::getTable('Billboard'); }

this is the my Doctrine Table

// public function getBillboardsForAUser($userId, $limit, $offset=0)
public function getBillboardsForAUser($userId,$limit,$offset=0)
{
$query = $this->createQuery('b')
->where('b.title=?',$title);
// ->where('b.owner_id = ?', $userId);
$followings = Doctrine::getTable('Follow')->getAllFollowing($userId);
foreach($followings as $following)

{ $query->orWhere('b.owner_id = ? ',$following->getOwnerId()); $query->orWhere('b.poster_id = ? ',$following->getOwnerId()); }

$query->orderBy('b.created_at DESC')
->limit($limit)
->offset($offset);
return $query->execute();

}

plz help me what is the problem.



 Comments   
Comment by Benjamin Eberlei [ 31/Mar/12 ]

Doctrine 1, not 2 ticket.





[DC-1051] Timestampable listener does not set timestamp fields on a copy of a Doctrine_Record Created: 14/Mar/12  Updated: 06/Sep/12

Status: Open
Project: Doctrine 1
Component/s: Timestampable
Affects Version/s: 1.2.3
Fix Version/s: None

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

Attachments: Text File Timestampable.php    

 Description   

The Timestampable Listener only sets the timestamp if the timestamp field has not been modified:

if ( ! isset($modified[$createdName])) {
  $event->getInvoker()->$createdName = $this->getTimestamp('created', $event->getInvoker()->getTable()->getConnection());
}

When saving a copy of a Doctrine_Record that doesn't already have the timestamp fields set fails to be updated, leading to integrity constraint violation ("created_at cannot be NULL"). The reason is that all unset fields in the copy are set to an instance of Doctrine_Null, which is considered to be modifed according to the condition tested for above. To fix the issue, I modified the code above to read:

if ( ! isset($modified[$createdName]) || $modified[$createdName] instanceof Doctrine_Null) {
  $event->getInvoker()->$createdName = $this->getTimestamp('created', $event->getInvoker()->getTable()->getConnection());
}


 Comments   
Comment by blopblop [ 06/Sep/12 ]

Your fix works great, I have also added the fix for the preupdate function and in one more place in the preinsert function.
Lines affected: 65, 73, 91.
Attached the file with the fixes:
( C:\php5\PEAR\symfony\plugins\sfDoctrinePlugin\lib\vendor\doctrine\Doctrine\Template\Listener\Timestampable.php )

[code]
/**

  • Set the created and updated Timestampable columns when a record is inserted
    *
  • @param Doctrine_Event $event
  • @return void
    */
    public function preInsert(Doctrine_Event $event)
    {
    if ( ! $this->_options['created']['disabled'])
    Unknown macro: { $createdName = $event->getInvoker()->getTable()->getFieldName($this->_options['created']['name']); $modified = $event->getInvoker()->getModified(); if ( ! isset($modified[$createdName]) || $modified[$createdName] instanceof Doctrine_Null) { $event->getInvoker()->$createdName = $this->getTimestamp('created', $event->getInvoker()->getTable()->getConnection()); } }

if ( ! $this->_options['updated']['disabled'] && $this->_options['updated']['onInsert']) {
$updatedName = $event->getInvoker()>getTable()>getFieldName($this->_options['updated']['name']);
$modified = $event->getInvoker()->getModified();
if ( ! isset($modified[$updatedName]) || $modified[$updatedName] instanceof Doctrine_Null)

{ $event->getInvoker()->$updatedName = $this->getTimestamp('updated', $event->getInvoker()->getTable()->getConnection()); }
}
}

/**
* Set updated Timestampable column when a record is updated
*
* @param Doctrine_Event $evet
* @return void
*/
public function preUpdate(Doctrine_Event $event)
{
if ( ! $this->_options['updated']['disabled']) {
$updatedName = $event->getInvoker()>getTable()>getFieldName($this->_options['updated']['name']);
//echo "updatedName: "; var_dump(updatedName);
$modified = $event->getInvoker()->getModified();
if ( ! isset($modified[$updatedName]) || $modified[$updatedName] instanceof Doctrine_Null) { $event->getInvoker()->$updatedName = $this->getTimestamp('updated', $event->getInvoker()->getTable()->getConnection()); }

}
}
[/code]
------------------

Also there is another problem too. If you dont disable the widgets of the fields updated_at and created_at, sometimes they are sending the date time information in the $form, and the function preUpdate doesnt update the update_at because the date time has been sent. The best option is to disable the widgets and form validation in global scope, here:
<?php

/**

  • Project form base class.
    *
  • @package dbvui
  • @subpackage form
  • @author Your name here
  • @version SVN: $Id: sfDoctrineFormBaseTemplate.php 23810 2009-11-12 11:07:44Z Kris.Wallsmith $
    */
    abstract class BaseFormDoctrine extends sfFormDoctrine
    {
    public function setup()
    {
    //Following code will remove Required validators from these fields.
    if (isset($this->validatorSchema))
    {
    if (isset($this->validatorSchema['created_at'])) { unset($this->validatorSchema['created_at']); }

if (isset($this->validatorSchema['updated_at']))

{ unset($this->validatorSchema['updated_at']); }

}

if (isset($this->widgetSchema))
{
//following code will remove fields from form
if (isset($this->widgetSchema['created_at']))

{ unset($this->widgetSchema['created_at']); }

if (isset($this->widgetSchema['updated_at']))

{ unset($this->widgetSchema['updated_at']); }

}
}
}

Comment by blopblop [ 06/Sep/12 ]

fixed





[DC-1049] error with Timestamp data Validation Created: 26/Feb/12  Updated: 17/Apr/14

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

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

Linux


Attachments: File Timestamp.php    

 Description   

The default value for timestamp is "0000-00-00 00:00:00", so
$e = explode('T', trim($value))
should be changed to
$e = explode(' ', trim($value))

public function validate($value)
{
if (is_null($value))

{ return true; }

$e = explode('T', trim($value));
$date = isset($e[0]) ? $e[0]:null;
$time = isset($e[1]) ? $e[1]:null;

$dateValidator = Doctrine_Validator::getValidator('date');
$timeValidator = Doctrine_Validator::getValidator('time');

if ( ! $dateValidator->validate($date))

{ return false; }

if ( ! $timeValidator->validate($time)) { return false; }

return true;
}






[DC-1048] MSSQL Connection Created: 16/Jan/12  Updated: 17/Apr/14

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

Type: Improvement Priority: Major
Reporter: Constantine Tkachenko Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Microsoft Windows Server 2008 R2; IIS 7; PHP 2.3.8; Doctrine 1.2.4; Symfony 1.4.16



 Description   

Function spliti(); is deprecated.
It need to be change to (in my own opinion):

$field_array = str_ireplace(' as ', ' as ', $field_array);
$aux2 = explode(' as ', $field_array);

thnx.






[DC-1046] Connection MSSQL replaceBoundParamsWithInlineValuesInQuery Created: 15/Dec/11  Updated: 17/Apr/14

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

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

Revision: 104


Attachments: Text File replaceBoundParamsWithInlineValuesInQuery.patch    

 Description   

Hello,

We found a bug in Doctrine1 MSSQL Connection.
When you would like to use the following functionality: find(One)By(p1,p2)
if you use the old functionality (Symfony 1.4 support it) like this: findBy("idAnddata", array("id" => ..., "date" => ..)), you got an MSSQL error, because the values wasn't changed.

Please find the patch for it, I hope it helps to you as well.

Kind regards
Peter



 Comments   
Comment by Peter Eisenberg [ 15/Dec/11 ]

Small changes:
Unfortunately the notice wasn't set in my test environment, and I didn't realized this small error:

please use the following instead of the original:
$replacement = 'is_null(\$value) ? \'NULL\' : \$this->quote(\$params[\'\\1\'])';

another case you got the following error: Use of undefined constant xxx - assumed xxx.

Kind regards,
Peter





[DC-1045] data-load with invalid filename leads to purging of all the data in the database Created: 06/Dec/11  Updated: 06/Dec/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

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

symfony 1.4


Attachments: Text File diff.patch    

 Description   

Adding an invalid filename to the data-load task results in purging of all the data in the database.

I am attaching a patch that checks the loaded data if there were any values actually loaded from the fixtures.






[DC-1043] Error:"When using..ATTR_AUTO_ACCESSOR_OVERRIDE you cannot.. name "data" ..." when running doctrine:build-schema ... except I'm NOT using that word Created: 30/Nov/11  Updated: 01/Dec/11

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

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

Mac OSX 10.6.8 running MAMP Pro 2.0.5 with PHP 5.3.6 ... this is a local symfony install which is also using the apostrophe cms.



 Description   

Was able to resolve this - see comment below - but still think it counts as a bug since the source of the error is so unclear

Hello,
I'm familiarizing myself with symfony at this point, but doctrine seems like a very accessible ORM tool overall. This install will also use the apostrophe plugin though that is more a client request and it is seeming to complicate a lot of issues from what I can see. Right now, I am just trying to create some db tables in schema.yml and build them with doctrine. When running $ php symfony doctrine:build-schema I get the following error: When using the attribute ATTR_AUTO_ACCESSOR_OVERRIDE you cannot use the field name "data" because it is reserved by Doctrine. You must choose another field name.

Which would be clear enough except I'm NOT using "data" as a field name in my schema file: here's what I'm using:

sfTravelLodgingLocationsType:
columns:
lodging_name:

{ type: string(255) }

lodging_code:

{ type: string(255) }

sfTravelLodgingLocations:
columns:
lodging_type_code:

{ type: integer, notnull: true }

name:

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

address:

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

city:

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

distance:

{ type: integer, notnull: true }

phone:

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

known_2b_sold_out:

{ type: boolean, notnull: true, default: 0 }

relations:
Travel_Lodging_LocationsType:

{ local: type_id, foreign: id }

I'm assuming this is a misnamed error call ... I have found a few references to that same error in other threads but none that resolve it



 Comments   
Comment by Maurice Stephens [ 01/Dec/11 ]

I was able to find a way to override the ATTR_AUTO_ACCESSOR_OVERRIDE with a method in the appConfiguration.class.php file

based on this thread ... http://stackoverflow.com/questions/7266293/attr-auto-accessor-override

But it is still a difficult error to troubleshoot ... not clear on what the reserved keyword "data" had to do with it ... considering I wasn't even using it in the schema

Would be interested in finding some resources that go into detail on the implications of the command line context that symfony relies on





[DC-1041] Using ->limit() in conjunction with many-to-many with mysql generates wrong SQL Created: 30/Nov/11  Updated: 30/Nov/11

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

Type: Bug Priority: Major
Reporter: Evgeniy Afonichev Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

mysql



 Description   

Using ->limit() in conjunction with many-to-many relationships with mysql leads to strange SQL generated. The condition id IS NULL is added in such case which is not correct at all.

Here's example schema

User:
  columns:
    username: { type: string(255) }
  relations:
    Operators:
      foreignAlias: Users
      class:        Operator
      refClass:     OperatorUser

Operator:
  columns:
    username: { type: string(255) }
    type:     { type: integer }


OperatorUser:
  columns:
    user_id:      { type: integer }
    operator_id:  { type: integer }
  relations:
    Operator:
      foreignAlias: OperatorUser
    User:
      foreignAlias: OperatorUser

And here's query which generates wrong SQL

Doctrine_Core::getTable('User')
  ->createQuery('User')
  ->leftJoin('User.Operators Operator')
  ->addWhere('Operator.type = ?', 1)
  ->limit(10)
  ->offset(0)
  ->execute()
;

Expected SQL generated:

SELECT u.id AS u__id, u.username AS u__username, o.id AS o__id, o.username AS o__username, o.type AS o__type
FROM user u
LEFT JOIN operator_user o2  ON (u.id = o2.user_id)
LEFT JOIN operator o        ON o.id = o2.operator_id
WHERE (o.type = '1')
LIMIT 10

Actual SQL generated:

SELECT u.id AS u__id, u.username AS u__username, o.id AS o__id, o.username AS o__username, o.type AS o__type
FROM user u
LEFT JOIN operator_user o2  ON (u.id = o2.user_id)
LEFT JOIN operator o        ON o.id = o2.operator_id
WHERE
  u.id IS NULL # is not expected
  AND (o.type = '1')
# there's no LIMIT clause

Seems like here's code which causes the bug https://github.com/doctrine/doctrine1/blob/master/lib/Doctrine/Query.php#L1307






[DC-1038] Missing Foreign Key Constraint in SQL Created: 24/Sep/11  Updated: 17/Apr/14

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

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


 Description   

Hi,

I have the problem, that a foreign key constraint is not created in the SQL schema. This occurs, when the primary key is not the column 'id'.

Here is an example:

User:
columns:
username:
type: string(30)
notnull: false
email:
type: string(80)
notnull: true
gender:
type: enum
values: [0,m,f]
notblank: true
notnull: true
birthday:
type: date

Address:
columns:
user_id:
type: integer(4)
unsigned: 1
notnull: true
primary: true
some_data:
type: string(100)
relations:
User:
local: user_id
foreign: id
foreignType: one

The foreign key from contacts to users is not created in der SQL schema. But if I delete the attribute 'primary' at the column 'user_id' (and a primary key 'id' will generated), everything is okay.

Can you help me please?

With kind regards
Stephan






[DC-1037] Migration does not quote identifiers when checking migration version Created: 07/Sep/11  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.3
Fix Version/s: None

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

Linux version 2.4.21-63.ELsmp (mockbuild@x86-005.build.bos.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-59)) #1 SMP Wed Oct 28 23:15:46 EDT 2009, Symfony 1.4.14-DEV, Oracle 11g



 Description   

I happen to be using Symfony 1.4.14-DEV (r33007) and am trying to setup migrations with Oracle, which is using Doctrine_Core::ATTR_QUOTE_IDENTIFIER. This issue is in core Doctrine.

To reproduce:

1. Make a change to your schema.yml
2. Create the migrations diff by executing php symfony doctrine:generate-migrations-diff
3. New file have been created at ./lib/migration/doctrine/*_version1.php
4. Try to migrate using command php symfony doctrine:migrate
5. Results in error:

ORA-00942: table or view does not exist : SELECT version FROM migration_version. Failing Query: "SELECT version FROM migration_version"

Cause: The current connection is using quoted identifiers, so the query used to create the migration_version table when migrations are first instantiated was properly created as "migration_version" (notice quotes). But the raw SQL query used in Doctrine_Migration::getCurrentVersion() is not quoting the table or column identifiers, so Oracle can't find the table.

There are several places in Doctrine_Migration where the table and column identifiers are not quoted, thus breaking migrations when using a database with strict rules on the case of identifiers.

Even though I'm developing against Oracle, this also likely affects other drivers.



 Comments   
Comment by John Kary [ 07/Sep/11 ]

Pull request open which quotes all identifiers in Doctrine_Migration and fixes this issue:
https://github.com/doctrine/doctrine1/pull/41





[DC-1036] Doctrine_Export_Oracle::alterTable() not properly quoting column identifier for change Created: 07/Sep/11  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2, 1.2.3
Fix Version/s: None

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


 Description   

This bug was introduced by the person reporting the bug #DC-592.

When trying to generate an ALTER TABLE statement with Doctrine_Core::ATTR_QUOTE_IDENTIFIER enabled, the column identifier is not quoted, and a blank identifier is instead quoted, generating the following SQL:

ALTER TABLE "mytable" MODIFY (username "" VARCHAR2(200))

The proper SQL to be generated should be:

ALTER TABLE "mytable" MODIFY ("username" VARCHAR2(200))


 Comments   
Comment by John Kary [ 07/Sep/11 ]

Pull request opened with failing test case and bug fix:
https://github.com/doctrine/doctrine1/pull/40





[DC-1033] [PATCH] Use multibyte version of strtolower Created: 28/Aug/11  Updated: 28/Aug/11

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

Type: Improvement Priority: Major
Reporter: Jonas Flodén Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.3.7, Symfony 1.4.13


Attachments: Text File 0001-Use-multibyte-version-of-strtolower.patch    

 Description   

While trying to develop a new Symfony frontend to an existing database - whcih unfortunately contains non-ascii character names - I ran into a lot of problems where non-ascii characters had been mangled.
After installing XDebug and digging into the issue I found that the use of strtolower on the column names was the issue, since it's not safe to use on UTF-8 strings.
I replaced all calls to strtolower with mb_strtolower and UTF-8 encoding which solved my issue. I don't know if that is the correct way of doing it or if there is a better way.
I saw one other use of mb_strtolower in doctrine and it was guarded with an if function exists... Also it might be an issue in other files as well...
I provide my patch file incase it is of any use.



 Comments   
Comment by Jonas Flodén [ 28/Aug/11 ]

Here is a Git pull request with the same patch:
https://github.com/doctrine/doctrine1/pull/39





[DC-1030] [PATCH] doctrine 1.2.4 ADD/DROP CONSTRAINT UNIQUE Created: 19/Aug/11  Updated: 19/Aug/11

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

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

Attachments: Text File symfony_0010_doctrine_fix_unique_add_drop.patch    

 Description   

Hi,

Adding/dropping UNIQUE CONSTRAINT doesn't work on PostgreSQL.

I'm attaching patch for this problem.

Best regards,
Michal






[DC-1026] PgSQL driver does not create indexes on foreign key columns Created: 08/Aug/11  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Szurovecz János Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Just like in Doctrine 2 (http://www.doctrine-project.org/jira/browse/DBAL-50):

The PostgreSQL database does not create indexes for foreign key columns, the user has to create them by hand. I think that indexes for foreign keys should be created automatically






[DC-1024] i am executing Created: 22/Jul/11  Updated: 26/Jul/11

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

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


 Description   

$query = new Doctrine_Query();
$query->select('e.entity_name,e.entity_id,s.id,s.parent_id,e.ffc_entity_id,c.country_id,c.country_name')
//$query->select('e.entity_name,e.entity_id,s.id,s.parent_id,e.ffc_entity_id,ea.Country')
->from('Entities e')
->leftJoin('e.EntityAddresses ea ON ea.entity_id = e.entity_id AND ea.address_type ="M"')
->leftJoin('ea.Country c ON ea.country = c.country_id')
->leftJoin('e.ActiveFactories s')
->where('e.status=1');
if(!empty($alpha))

{ $query->andWhere("e.entity_name like '".$alpha."%'"); }

$query->andWhere("s.company_id=".$parentId)
->andWhere("e.entity_type=2")
->andWhere('s.status=1')
->groupBy('e.entity_id');






[DC-1023] i am executing doctrine type query i am geting error please gave me reply my query i am typed in descrition field Created: 24/Jul/11  Updated: 26/Jul/11

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

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


 Description   

$query = new Doctrine_Query();
$query->select('e.entity_name,e.entity_id,s.id,s.parent_id,e.ffc_entity_id,c.country_id,c.country_name')
//$query->select('e.entity_name,e.entity_id,s.id,s.parent_id,e.ffc_entity_id,ea.Country')
->from('Entities e')
->leftJoin('e.EntityAddresses ea ON ea.entity_id = e.entity_id AND ea.address_type ="M"')
->leftJoin('ea.Country c ON ea.country = c.country_id')
->leftJoin('e.ActiveFactories s')
->where('e.status=1');
if(!empty($alpha))
{
$query->andWhere("e.entity_name like '".$alpha."%'");
}
$query->andWhere("s.company_id=".$parentId)
->andWhere("e.entity_type=2")
->andWhere('s.status=1')
->groupBy('e.entity_id');






[DC-1022] Doctrine migration does not set version when MySQL autocommit is false Created: 26/Jul/11  Updated: 17/Apr/14

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

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

RHEL 6.0, mysql 5.1.52


Attachments: Text File migration.patch    

 Description   

With autocommit set to off in mysqld, Doctrine_Migration::setCurrentVersion() does not have any effect. This is because the method uses raw PDO calls, which are discarded without either autocommit or an explicit COMMIT;.

We patched Doctrine as in the attachment. It works for us, but may not be the best general solution.

The patch only fixes this one issue. There are likely many areas in Doctrine that rely upon autocommit behavior in MySQL. We will continue to look for them, and supply patches as we find them. However, as we are only concerned about MySQL, our solutions will probably not apply to other PDO drivers.






[DC-1020] In the Timestampable Listener, the 'alias' behavior option is not used when determining the database fieldname Created: 19/Jul/11  Updated: 17/Apr/14

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

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

PHP 5.3.5, MySQL 5.5.9; as well as PHP 5.3.6, MySQL 5.0.92


Attachments: Zip Archive Doctrine_Timestampable_Alias.zip    

 Description   

I noticed this issue after setting up timestampable behavior on an aliased column in a legacy table:

 
<?php

abstract class Content_Article extends Doctrine_Record
{

  public function setTableDefinition()
  {
    $this->setTableName('t_content');
    
    $this->hasColumn('id', 'integer', 11, array('primary' => true, 'autoincrement' => true));
    // ...
    $this->hasColumn('datePost as posted_at', 'timestamp');
    $this->hasColumn('dateEdit as updated_at', 'timestamp');
    // ...
    
  }
  
  public function setUp()
  { 
    // ..
    $this->actAs('Timestampable', array('created' => array( 'name' => 'datePost',
                                                            'alias' => 'posted_at'),
                                        'updated' => array( 'name' => 'dateEdit',
                                                            'alias' => 'updated_at')));
  }

}

Before I added timestampable to this model, I was setting the timestamp fields manually, which worked fine.

I had to look at the source to find the alias option in the timestampable behavior, since it does not appear to be in the 1.2 documentation. (If this issue is invalid because it's not an officially supported option, I apologize).

After I added timestampable to the model, Doctrine began throwing an exception when I tried to save a new record:

Error: Doctrine_Record_UnknownPropertyException [ 0 ]: Unknown record property / related component "datePost" on "Content_Article" ~ [...]/Doctrine-1.2.4/Doctrine/Record/Filter/Standard.php

It appears that the alias option is used when setting the table definition in the behavior template, but not used by the template's listener when creating, updating, etc.

I'm attaching a zip with a copy of the changes I made to fix this in 1.2.4 and a git patch.






[DC-1015] bindComponent not called before inherited classes base definitions Created: 04/Jul/11  Updated: 04/Jul/11

Status: Open
Project: Doctrine 1
Component/s: Inheritance, Schema Files
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Adrian Nowicki Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

symfony 1.4



 Description   

If I define a base model:

Entity:
connection: other
columns:
name: {}
size: {}

and inherited model:

Box:
inheritance:
extends: Entity
type: column_aggregation

Then file with base definition of Box does not contain bindComponent sentence to bind Box model with connection specified for Entity model.






[DC-1014] Geographical behaviour generates wrong INSERT statement in PostgreSQL if latitude/logitude not specified Created: 01/Jul/11  Updated: 01/Jul/11

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

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

Symphony 1.4, PostgreSQL 8.4.8



 Description   

Added "Geographical" behaviour to an entity:

 
ZipCode:
  actAs: [Geographical]
  columns:
    code: string
    [...]

Using the standard Symfony-generated admin manager, when trying to insert a new record without specifying both latitude and longitude, Doctrine generates a wrong INSERT statement for PostgreSQL, including latitude and longitude as '' (empty string)

 
Doctrine_Connection->exec('INSERT INTO zip_code (hidden, code,  country_id, latitude, longitude) VALUES (?, ?, ?, ?, ?)', array('false', '20133', '1', '', ''))

This cause this error:
SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for type double precision: ""

Workaround

explicitly specifying float type for latitude and longitude...

 
  actAs: 
    Geographical:
      latitude: {type: float}
      longitude: {type: float}

...still generate the column correctly as double precision in the database, but will not cause any error on inserting records.






[DC-1013] [PATCH] Doctrine ignores unique option for integers (PostgreSQL) Created: 29/Jun/11  Updated: 18/Aug/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: None
Fix Version/s: None

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

Attachments: Text File integer_unique.patch    

 Description   

This issue is exactly the same as DC-252, but refers to PostgreSQL



 Comments   
Comment by MichalKJP [ 18/Aug/11 ]

Your patch fixed the problem for me. Thanks!





[DC-1011] wierd behaviour with setTableName - table name doesn't get set Created: 28/Jun/11  Updated: 28/Jun/11

Status: Reopened
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.3
Fix Version/s: None

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

Linux 2.6.35-28-generic #50-Ubuntu SMP Fri Mar 18 19:00:26 UTC 2011 i686 GNU/Linux
PHP 5.3.3-1ubuntu9.5


Attachments: File attribute_set.php    

 Description   

if i create class called Attribute_set that extends Doctrine_Record and setTableName in setUpTableDefinintion like in documentation setting up models section, the table name appears not to be set
getTableName returns "doctrine_record_abstract"

any joins or relations fail.

if i set it in the setUp function the setTableName appear working and returns "attribute_sets" table name. This only happens with this particular class, and relations have no effect.

I attached class example i'm expiriencing problems with, that should help reproducte this issue



 Comments   
Comment by Justinas [ 28/Jun/11 ]

fixed misstype and it appears that it was not the problem, i get the same:

Base table or view not found: 1146 Table 'db.doctrine_record_abstract' doesn't exist

maybe attribute_set is somekind reserved word in doctrine library ?

Comment by Justinas [ 28/Jun/11 ]

the problem appears to come from Doctrine Formatter





[DC-1010] When putting a subquery in the where clause which includes a join and a limit the limit subquery algorithm mistakenly modifies the subquery Created: 21/Jun/11  Updated: 21/Jun/11

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

Type: Bug Priority: Major
Reporter: will ferrer Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

XP Xamp



 Description   

I have fixed this in my own version of doctrine but unfortunately I am to far diverged from the trunk to offer a patch.

here is a test case:

public function testSubqueryInWhereWithJoinAndLimit()
    {
        $q = new Doctrine_Query();
        $q->select('u.id');
        $q->from('User u');
        $q->where('u.id NOT IN (SELECT a.id FROM User u2 LEFT JOIN u2.Album a LIMIT 1)');
        $this->assertEqual($q->getSqlQuery(), 'SELECT e.id AS e__id FROM entity e WHERE (e.id NOT IN (SELECT a.id AS a__id FROM entity e2 LEFT JOIN album a ON e2.id = a.user_id WHERE (e2.type = 0) LIMIT 1) AND (e.type = 0))');
    }

To fix the issue I changed this line in Doctrine_Query as follows:

if ( ( ! empty($this->_sqlParts['limit']) || ! empty($this->_sqlParts['offset'])) && $needsSubQuery && $limitSubquery) {

=

if ( ( ! empty($this->_sqlParts['limit']) || ! empty($this->_sqlParts['offset'])) && $needsSubQuery && $limitSubquery && !$this->isSubquery()) {

Hope that helps.

Sincerely

Will Ferrer






[DC-1008] missing oci_type in Doctrine_Adapter_Statement_Oracle->bindParam Created: 31/May/11  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Tomasz Madeyski Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

in bindParam method there is:
switch ($type) {
case Doctrine_Core::PARAM_STR:
$oci_type = SQLT_CHR;
break;
}
I think there should be other oci_types too. I had to add:
case Doctrine_Core::PARAM_INT:
$oci_type = SQLT_INT;
because I got ORA-06502: PL/SQL: numeric or value error: character string buffer too small. while executing
$stmt->bindParam(":result", $result, Doctrine_Core::PARAM_INT);

After adding SQLT_INT everything is ok






[DC-1004] ATTR_TBLNAME_FORMAT not used when creating models from database Created: 08/May/11  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: 1.2.3

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

Attachments: File doctrine_bug_diff.diff    

 Description   

if you set prefix to "xyz_%s" and have the model "BackgroundColor" it will become the table => "xyz_background_color"
if you have the table "xyz_background_color" with unknown model and create the the model from the table, you will get => "XyzBackgroundColor".

The fix (diff):

368a369,370
> $tablePrefix = $manager->getAttribute(Doctrine_Core::ATTR_TBLNAME_FORMAT);
>
381d382
<
385c386
< $definition['className'] = Doctrine_Inflector::classify(Doctrine_Inflector::tableize($table));

> $definition['className'] = Doctrine_Inflector::classify(Doctrine_Inflector::tableize(preg_replace(sprintf('/\A%s\z/', str_replace('%s', '(.*?)', $tablePrefix)), '$1', $table)));
396c397
< $class = Doctrine_Inflector::classify(Doctrine_Inflector::tableize($table));

> $class = Doctrine_Inflector::classify(Doctrine_Inflector::tableize(preg_replace(sprintf('/\A%s\z/', str_replace('%s', '(.*?)', $tablePrefix)), '$1', $table)));



 Comments   
Comment by Robin Parker [ 08/May/11 ]

The diff output as .diff





[DC-1002] Typos in filename and php tags Created: 02/May/11  Updated: 17/Apr/14

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

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


 Description   

Two typos in Doctrine files prevents usage of symfony core_compile.yml system, or any similar compiler system :

  • According to its class name, "Doctrine_Validator_HtmlColor", the file "Doctrine/Validator/Htmlcolor.php", should be named "HtmlColor.php" (note the uppercase "C" of "Color")
  • The php tag of the file "Doctrine/Locking/Exception.php" is uppercased. It should be "<?php" instead of "<?PHP"





[DC-1000] Wrong parsing on HAVING clause Created: 28/Apr/11  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Pierrot Evrard Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

symfony 1.4.12-DEV / Windows XP / Apache 2.0 / MySQL 5.1.37 / PHP 5.3.0


Attachments: Text File Doctrine-DC-1000.patch    

 Description   

With Doctrine::ATTR_QUOTE_IDENTIFIER enabled, when you launch a query with a complex having clause, Doctrine_Query_Having class does not handle it correctly.

By example, when you track the having clause interpretation:

$query->addHaving( 'SUM( IF( s.id = ? , 1 , 0 ) ) = 0' , 7 );

At some point, Doctrine_Query_Having at line 70 return something like "`s10`.`id = ?`" instead of "`s10`.`id` = ?".

I just fix it using:

return $this->query->parseClause($func);

instead of:

return $this->_parseAliases($func);

Now, the parseAliases function is not used anymore...

See patch attached...

Loops






[DC-999] Query cache key can be incorrectly generated Created: 28/Apr/11  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Caching, Query
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jakub Zalas Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None


 Description   

1. We have two versions of the application on the same server.
2. Second application has an updated database. New field is added to one of the models.
3. When the second app is hit first, query is stored in APC.
4. First app finds cached query and tries to call it. Exception is thrown as it doesn't know anything about the new field yet.

Situation often happens on shared development machine when one developer adds a field but others don't have in their models yet. It also happens on staging server if it's shared with production.

I suspect it only affects queries without explicitly listed fields.

To quickly fix the issue in my symfony project I extended Doctrine_Cache_Apc to implement namespaces (https://gist.github.com/944524). More appropriate place to fix it would be Doctrine_Query_Abstract::calculateQueryCacheHash().



 Comments   
Comment by Pablo Grass [ 27/Jun/11 ]

Could this be a duplicate of http://www.doctrine-project.org/jira/browse/DC-389 ?
Are you querying a model with a *-to-many relation and applying a limit?

See also http://www.doctrine-project.org/documentation/manual/1_2/en/dql-doctrine-query-language:limit-and-offset-clauses:the-limit-subquery-algorithm





[DC-998] MySQL Driver possibly subject to sql injections with PDO::quote() Created: 19/Apr/11  Updated: 17/Apr/14

Status: Open
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, 1.2.0-BETA2, 1.2.0-BETA3, 1.2.0-RC1, 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

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

All



 Description   

Prior to 5.3.6, the MySQL PDO driver ignored the character set parameter to options. Due to MySQL's C api (and MySQLND), this is required for the proper function of mysql_real_escape_string() (the C API call). Since PDO uses the mres() C call for PDO::quote(), this means that the quoted string does not take into account the connection character set.

Starting with 5.3.6, that was fixed. So now if you pass the proper character set to PDO via driver options, sql injection is impossible while using the PDO::quote() api call.

PDO proof of concept
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK;';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
            FROM INFORMATION_SCHEMA.TABLES
            WHERE TABLE_NAME LIKE ".$pdo->quote($string)." LIMIT 1;";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());

Expected Result: `int(0)`.
Actual Result: `int(1)`.

There are 2 issues to fix. First, the documentation does not indicate that you can pass the `charset` option to the MySQL Driver. This should be fixed so that users are given the proper option to set character sets.

Secondly, `Connection::setCharset()` should be modified for MySQL to throw an exception, since the character set is only safely setable using the DSN with PDO. This is a limitation of the driver and could be asked as a feature request for the PHP core. Either that, or a big warning should be put on the documentation of the API to indicate the unsafe character set change

Note that this is the same issue reported for Doctrine2 with link: http://www.doctrine-project.org/jira/browse/DBAL-111



 Comments   
Comment by Fabien Potencier [ 23/May/11 ]

Any news on this one? It has been "fixed" in Doctrine2 and must be also fixed in Doctrine1.





[DC-997] Doctrine collections are overwritten when created by inner join queries that agree on the WHERE Created: 13/Apr/11  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Richard Forster Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

OS X 10.6.6 with PHP 5.3.3, Windows with PHP 5.3.1


Attachments: File models.yml     Zip Archive test.zip    

 Description   

In brief:
Doing $result1 = Doctrine_Query::create()>... followed by $result2 = Doctrine_Query::create()>... can lead to a situation where the content of $result1 has become the value in $result2.

In detail:
The attached models.yml defines two simple tables with a One-to-Many relationship; we have people and names and each person can have multiple names. The DB can be propagated along the lines of:

INSERT INTO `tblname` VALUES (1,1,'alpha'),(2,2,'beta'),(3,3,'gamma'),(4,4,'delta'),(5,5,'epsilon'),(6,1,'aleph');
INSERT INTO `tblperson` VALUES (1),(2),(3),(4),(5);

Applying the query:

$results1 = Doctrine_Query::create()
->from('Person ppa')
->innerJoin('ppa.Name n')
->where('ppa.id = ?', 1)
->andWhere('n.text = ?', 'alpha')
->execute()
->getFirst()
->Name;

and then producing output though

print 'Results (1): '.count($results1)."\n";
foreach ($results1 as $result) print $result['text'] . "\n";
print "\n\n";

produces the expected:

Results (1): 1
alpha

Doing a similarly query to a new variable:

$results2 = Doctrine_Query::create()
->from('Person ppa')
->innerJoin('ppa.Name n')
->where('ppa.id = ?', 1)
->andWhere('n.text = ?', 'aleph')
->execute()
->getFirst()
->Name;

and printing with

print 'Results (2): '.count($results2)."\n";
foreach ($results2 as $result) print $result['text'] . "\n";
print "\n\n";

produces the expected:

Results (2): 1
aleph

but printing out the first result object again at this point gives:

Results (1): 1
aleph

which is unexpected - "aleph" rather than "alpha".

If, the second query was altered to

->where('ppa.id = ?', 2)
->andWhere('n.text = ?', 'beta')

then all three output results are as expected.

test.zip contains corresponding test files.






[DC-996] UPDATE query generate ambiguous statement Created: 13/Apr/11  Updated: 13/Apr/11

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

Type: Bug Priority: Major
Reporter: John Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 2
Labels: None
Environment:

MAMP on MacBook Pro 10.6.7, with Symfony 1.4.9



 Description   

When creating an UPDATE query, the table names are not aliased like in a SELECT statement. This causes ambiguous column names when JOINING in an UPDATE.

E.g.
$q = $this->createQuery('st')
->update('SomeTable st')
->set('st.position','st.position + 1')
->leftJoin('st.SomeOtherTable sot ON st.some_id = sot.id')
->where('st.id <> ?', $someId)
->andWhere('sot.some_column = ?', $someValue)

The generated SQL for this is :
UPDATE some_table
LEFT JOIN some_other_table sot ON st.some_id = sot.id
SET position = position + 1, updated_at = 2011-04-13 11:01:03, updated_at = 2011-04-13 11:01:03
WHERE (id <> 4 AND some_column = 7)

Clearly here "updated_at" and "id" are ambiguous columns. Why the tables are not automatically aliased with unique aliases like in a SELECT statement, and the aliases written before the column name ?

Thanks.






[DC-994] Doctrine_Data_Import creates unnecessary transactions, big slowdown Created: 05/Apr/11  Updated: 05/Apr/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Krzysztof Bociurko / ChanibaL Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL, symfony doctrine:load-data


Attachments: Text File Doctrine_Data_Import-wrap-in-transaction.patch    

 Description   

While trying to load ~25M data fixtures (one big table with relations to 4 smaller ones, sfGuard included in that, row size around 500 bytes) in Symfony i ended up waiting around 80 minutes, while waiting i looked at what could have make it so dreadfully slow. Turns out, when Doctrine_Data_Load gets UnitOfWorks it executes save() on every new record. Save makes it's own transaction - not a problem if it's nested, but when this is the main transactions, 70000 of them make quite a difference. Remember - one of the main factors of DBMS speed is transactions/second.

I patched Doctrine_Data_Import to wrap everything in one transaction, and the results were great - from 80 minutes i got down to around 10. Still, not as fast as it should be but now it's usable. The time difference is notable also in smaller dumps.

Patch to speed up loading times included, would be great if you add it to trunk.

Please note - i have not checked this patch with any other setup or DBMS, please do so.

Also i have noticed something that might be a problem in much larger loads - if wrapping in a single transaction, my total memory usage went up for about 500M higher than in 70000 transactions. At some point, about 5 minutes in the process some kind of garbage collector fired and freed around 1 gig, so perhaps on larger dumps it might be a good idea to wrap the import not in one, but more transactions (like one transaction every 10000 operations).






[DC-992] I18n - Translated fields are not deleted when record in master table is deleted Created: 03/Apr/11  Updated: 28/Oct/11

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

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

Windows XP, xampp 1.7.3 (PHP 5.3.1)



 Description   

I have used I18n behavior for my application using the following:

public function setTableDefinition()
{
        $this->setTableName('products');

        $this->hasColumn('id', 'integer', 4, 
            array('fixed' => true, 
                  'primary' => true, 
                  'autoincrement' => true));

        $this->hasColumn('permalink', 'string', 255,
            array('notnull' => true));
        
        $this->hasColumn('title', 'string', 255, 
            array('notnull' => true));
            
        $this->hasColumn('teaser', 'string', 255, 
            array('notnull' => true));
            
        $this->hasColumn('content', 'clob', 32767);
}

public function setUp()
{   
        $this->actAs('I18n', array(
                'fields' => array('title', 'teaser', 'content')
            )
        );
}

Doctrine has created two tables db named products and products_translation.

Insert and update of the record is working fine but when i perform a deletion of a record, the record is deleted from the products table but the translations stored in products translation table are not deleted.



 Comments   
Comment by Justinas [ 28/Oct/11 ]

if you are not using transaction type tables like innoDB you need to set 'appLevelDelete' => TRUE option for I18n
it's not documented feature as i found out.

$this->actAs('I18n', array(
'fields' => array('title', 'teaser', 'content'),
'appLevelDelete' => TRUE,
)
);





[DC-991] Views abstraction model Created: 28/Mar/11  Updated: 28/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Schema Files
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Documentation Priority: Major
Reporter: Jesus Farías Lacroix Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

all



 Description   

View abstraction model

Hi, i've been using doctrine from about six months, i'm not an expert but i know the basics and this has been enough for me and my web-app requirements. The problem begins cause i need a kind of "dynamic table model" in other words an specific one table's abstraction, i thought implement a view for this purpose, but i can't figure out how define the BaseModel for the view to use it like a table, thus allowing the use of methods like save(), find() and build (logicals) relationships with others entities. in few words: can i build a table model from a query/view?, it is possible? i read the posts from above but this issue still being not realy clear at all for me.

me realy will apreciate any help, thanks in advance.

Regards.






[DC-989] Doctrine_Connection::execute() and Doctrine_Connection::exec() fail if Doctrine_Event::skipOperation() is triggered Created: 22/Mar/11  Updated: 22/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Connection
Affects Version/s: 1.2.3
Fix Version/s: None

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


 Description   

In order to generate SQL from migrations, an event listener was attached to the migration system to monitor for preQuery and preExec events.

In an attempt to prevent the migration from additionally writing the query to the database, the skipOperation method was triggered, and supposedly allowed for n the execute() and exec() methods of Doctrine_Connection

eg. Doctrine_Connection::execute()
 
$this->getAttribute(Doctrine_Core::ATTR_LISTENER)->preQuery($event);

if ( ! $event->skipOperation) {
    $stmt = $this->dbh->query($query);
    $this->_count++;
}
$this->getAttribute(Doctrine_Core::ATTR_LISTENER)->postQuery($event);

unfortunately setting this option in the event listener breaks execution of the migration system as the $count/$stmtn variables (used in the methods) are no longer defined, triggering E_NOTICE, and the fetch* methods (eg fetchColumn) also break as they are chaining methods without testing for the return. theerfore, even if the $stmnt variable was created as initially null, the system would still throw an E_FATAL as the NULL variable doest provide the ::fetchColumn() methods (etc).

Quite a serious flaw as 2 areas of code do not provide a consistent approach to how to work with events.






[DC-988] migrations should allow generation of SQL in place of DB manipulation Created: 21/Mar/11  Updated: 21/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.3
Fix Version/s: None

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


 Description   

At present migrations only allow for direct manipulation of the underlying database. However, many enterprise release processes disallow automated manipulation of databases (especially Oracle) due to a number of reasons (eg placing different objects in different table spaces).

Because of this, it is preferable for developers to auto generate SQL and then hand over the specialist DBAs who may then filter/alter as needed on a per-environment basis.

this is currently very easy to achieve with initial database query generation, as outputting SQL is an option, but there is no such option for migration scripts. Therefore I would like to request this option to be added to the migration class.






[DC-986] createIndexSql and dropConstant do not correct set index name suffix Created: 21/Mar/11  Updated: 23/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.3
Fix Version/s: None

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

linux, oracle



 Description   

Current export methods are inconsitent with index/constraint name suffix (defautl %_idx). Both createConstraintSql() and dropIndex() methods correctly set the suffix, but dropConstraint() and createIndexSql() do not.

this causes associated down() methods to fail when reverting changes to indexes/constraints

Erros occur in : Export.php - lines 137 and 473






[DC-985] doctrine migration does not use tblname_format Created: 21/Mar/11  Updated: 21/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.3
Fix Version/s: None

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

linux, oracle



 Description   

Migration commands update the database without correcting the default tablename using pre-set tblename_format parameters in databases.yml.

There is a method for updating the tablename, but this appears to not be used by any script.






[DC-984] Pessimistic locking locks entire table rather than record Created: 16/Mar/11  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Barry O'Donovan Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Standard LAMP stack using current SVN from http://svn.doctrine-project.org/branches/1.2/lib/Doctrine/Locking/Manager


Attachments: File Doctrine_Locking_Manager_Pessimistic.diff    

 Description   

When using pessimistic locking as described in:

http://www.doctrine-project.org/projects/orm/1.2/docs/manual/component-overview:locking-manager:examples/zh

the locking manager locks the entire table rather than the specific object.

This should be clear from the attached patch which corrects the issue (assuming I have correctly interpreted the intention of pessimistic locking!).

The current behavior will have worked as expected for users but it will have locked far more than was intended and may thus have affected performance.

NB: I can confirm this works for non-composite keys but please review and test for composite keys as I have no such tables to hand.



 Comments   
Comment by Barry O'Donovan [ 18/Oct/11 ]

Folks - just wondering if anyone had a chance to look at this as, while not critical, it does appear to be a genuinely major performance issue.

Comment by Grégoire Paris [ 13/Dec/12 ]

Duplicate with more information : http://www.doctrine-project.org/jira/browse/DC-185





[DC-983] Fixtures loading is repeated for each database connections Created: 08/Mar/11  Updated: 08/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures
Affects Version/s: None
Fix Version/s: None

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


 Description   

Bug found when working on project ma-residence.fr. Data loading was repeated twice, and in the second run, empty rows were inserted in database, resulting in major headache in development team.

A same flush tree is built for each connections. It results in multiple loops of data load when there is more than one connection.



 Comments   
Comment by Ludovic Vigouroux [ 08/Mar/11 ]

A proposition to fix it is on github https://github.com/ludovig/doctrine1





[DC-982] Options for building models aren't forwarded from CLI to Manager instance Created: 04/Mar/11  Updated: 04/Mar/11

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

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


 Description   

I.e.: generate_models_options and classPrefix option isn't forwared from CLI configuration to create table task (which uses the Manager's options).






[DC-981] Class prefix isn't being appended when importing data Created: 04/Mar/11  Updated: 04/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Cli
Affects Version/s: 1.2.3
Fix Version/s: None

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


 Description   

Configuration:

Doctrine_Manager::getInstance()->setAttribute(Doctrine_Core::ATTR_MODEL_CLASS_PREFIX, 'Foo_');

Schema:

Bar:
columns:
baz: int

Fixtures:

Bar:
Bar_1:
baz: 1

Error on importing data: "Couldn't find class Bar."

Doctrine should use Foo_Bar class for Bar model instead Bar class.






[DC-979] Doctrine save() only checks one level deep on one-to-one relations. Created: 27/Feb/11  Updated: 27/Feb/11

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

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

MySQL 5.1.38, PHP 5.3.3



 Description   

Updating/saving an object fails when trying to update the nth-level of an existing object/relation where n is more than one level away from the root node of one-to-one relation chain. For example, with the yaml model below the following does not update the name of the Company object:

Image->Product->Category->Company->name = "Acme".

If "Product" has no changes it appears to stop checking for changes there. If we do a save on a one-to-many relation chain such as the following, it works fine:

Company->Category->Product->Image->name = "image1.jpg"

I was able to fix this issue by modifying the saveRelatedLocalKeys() function in UnitOfWork.php to use isModified() with deep=true:

if ($obj instanceof Doctrine_Record && $obj->isModified(true)) {

This works but I'm not sure if changing this has any repercussions on more complex queries.


detect_relations: true
options:
collate: utf8_general_ci
charset: utf8
type: InnoDB

Company:
tableName: Company
columns:
id:
type: integer(4)
primary: true
notnull: true
autoincrement: true
name:
type: string(45)

Category:
tableName: Category
columns:
id:
type: integer(4)
primary: true
notnull: true
autoincrement: true
companyId:
type: integer(4)
notnull: true
name:
type: string(45)
relations:
Company:
class: Company
local: companyId
foreign: id
foreignAlias: categories
onDelete: cascade
onUpdate: cascade
indexes:
fk_Category_Company1:
fields: [companyId]

Product:
tableName: Product
columns:
id:
type: integer(4)
primary: true
notnull: true
autoincrement: true
categoryId:
type: integer(4)
notnull: true
name:
type: string(45)
relations:
Category:
class: Category
local: categoryId
foreign: id
foreignAlias: products
onDelete: cascade
onUpdate: cascade
indexes:
fk_Product_Category1:
fields: [categoryId]

Image:
tableName: Image
columns:
id:
type: integer(4)
primary: true
notnull: true
autoincrement: true
productId:
type: integer(4)
notnull: true
name:
type: string(45)
relations:
Product:
class: Product
local: productId
foreign: id
foreignAlias: images
onDelete: cascade
onUpdate: cascade
indexes:
fk_Image_Product1:
fields: [productId]






[DC-974] generateFile = true - problematic implementation, see symfony ticket #4522 Created: 17/Feb/11  Updated: 17/Feb/11

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

Type: Bug Priority: Major
Reporter: Georg Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 2
Labels: None
Environment:

symfony



 Description   

see http://trac.symfony-project.org/ticket/4522

When using a behaviour with generateFile=true, som eproblematic issues occur:

Let's take for example i18n:

schema.yml
...
actAs:
fields: [text]
generateFiles: true
generatePath: <?php echo sfConfig::get('sf_lib_dir') ?>/model/doctrine/translations

1) The translation model class and it's base class are not created with generate.php (aka symfony doctrine:build --model), but every time a translation model is used. This is not the expected behaviour, because
a) this makes autoloading these classes impossible.
b) the APC cache always sees a new change time, and recaches the fiels. This results in a quick fragmentation of the cache with segmentation faults in the long run.
2) The permissions for the created files are wrong. Normal executable php scripts should not be writable by the web server (admitting that with the current implementation, this is not problem, because the files are created again for each request)
3) The path is hard coded. This brakes deployment by svn update, and I would prefer not to build models on a production server.

Proposal:

  • generate the files at build model time
  • hopefully find a solution with the path

I realize that most development resources are now in the new doctrine, but this issue (especially the apc fragmentation) is a huge problem for me. If you won't fix it, let me know, then I would try to propose a patch. I checked the code, and the building and behaviour internal part of doctrine are not too well documented, and my patch would be far from perfect.






[DC-973] Statements with empty results are not correctly closed Created: 17/Feb/11  Updated: 17/Feb/11

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

Type: Bug Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Statements that return no result are not correctly closed in Doctrine_Hydrator_Graph::hydrateResultSet().

Oracle has limited number of opened cursors, and this bug prevents unsing doctrine in batch task like indexing models with sfSolrPlugin.

Oracle throws an error `ORA-01000: maximum open cursors exceeded : ` in my case after indexing only 100 records.

I'll send a pull request via github for this issue.






[DC-971] Tree result sets hydrators are checking for column level not field level Created: 16/Feb/11  Updated: 16/Feb/11

Status: Open
Project: Doctrine 1
Component/s: Nested Set
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Tree hierarchy hydrators (Doctrine_Collection::toHierarchy and Doctrine_Array_Hierarchy_Driver::hydrateResultSet) are checking wheter the column `level` exists.

The level column can be aliased, and for oracle, it is required to do so. Therefor it is better to check, whether the aliased field level exists.

Patch included in pull request






[DC-968] I18n and PostgreSQL and DmVersionable Created: 03/Nov/10  Updated: 15/Feb/11

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

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

PHP 5.3.2, PostgreSQL 8.4.5, Diem 5.1.x



 Description   

I am using PHP 5.3.2 and PostgreSQL 8.4.5, Diem passed all checks in green - OK.

I started with "A week of Diem Ipsum" and all went ok until I reached building of blog engine. Blog engine example fails in step:

php symfony doctrine:migrate

with error message:

The following errors occurred:

    * SQLSTATE[42830]: Invalid foreign key: 7 ERROR: there is no unique constraint matching given keys for referenced table "article_translation". Failing Query: "ALTER TABLE article_translation_version ADD CONSTRAINT article_translation_version_id_article_translation_id FOREIGN KEY (id) REFERENCES article_translation(id) ON UPDATE CASCADE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE"
    * SQLSTATE[25P02]: In failed sql transaction: 7 ERROR: current transaction is aborted, commands ignored until end of transaction block. Failing Query: "CREATE INDEX article_image ON article (image)"
    * SQLSTATE[25P02]: In failed sql transaction: 7 ERROR: current transaction is aborted, commands ignored until end of transaction block. Failing Query: "CREATE INDEX article_author ON article (author)"
    * SQLSTATE[25P02]: In failed sql transaction: 7 ERROR: current transaction is aborted, commands ignored until end of transaction block. Failing Query: "CREATE INDEX article_translation_id ON article_translation (id)"
    * SQLSTATE[25P02]: In failed sql transaction: 7 ERROR: current transaction is aborted, commands ignored until end of transaction block. Failing Query: "CREATE INDEX article_translation_version_id ON article_translation_version (id)"

I removed i18n support in blog engine example and after that migrate went ok. But in Admin interface when I wanted to add
blog article, although Diem confirmed it saved article, article would not show up in the list, I checked db table, it was empty also.
Further, if I try to loremize, for 1 fixture I get no error but table is again empty, and for more fixtures then 1, Diem reports error:

SQLSTATE[25P02]: In failed sql transaction: 7 ERROR: current transaction is aborted, commands ignored until end of transaction block.

Again I reviewed the model and removed DmVersionable, migrated again and after that I could loremize or create articles without errors.

Additionally, not related directly to this blog engine example but doctrine related, I noticed errors in Diem Admin interface
itself when I try to access System->Configuration->Settings . If I access System settings over link
admin_dev.php/system/configuration/settings/index it shows settings. But when I click on
dmin_dev.php/system/configuration in menu path and after again to settings
admin_dev.php/system/configuration/settings/index, error is generated:

500 | Internal Server Error | Doctrine_Connection_Pgsql_Exception
SQLSTATE[08P01]: <>: 7 ERROR: bind message supplies 1 parameters, but prepared statement "pdo_stmt_00000008" requires 2

Are this bugs corrected?






[DC-967] Problems with fetchArray() combined with leftJoin() by using aliases of columns Created: 13/Feb/11  Updated: 13/Feb/11

Status: Open
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Arnoldas Lukasevicius Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Symfony Framework v1.3.8, Windows 7



 Description   

They are some strange problems with hydration to array combined with aliases of columns and JOINS. Let's see this example:

$q = Doctrine_Query::create ()
->select('c.id AS id, c.path AS path, c.name AS name, cbc.product_count')
->from('Category c')
->leftJoin('c.CategoryBrowserCache cbc');

$categories = $q->fetchArray();

This example will throw exception: "The root class of the query (alias lc) must have at least one field selected."

OK. Let's change code a little bit. Let's add alias for cbc.product_count column too:

$q = Doctrine_Query::create ()
->select('c.id AS id, c.path AS path, c.name AS name, cbc.product_count AS product_count')
->from('Category c')
->leftJoin('c.CategoryBrowserCache cbc');

$categories = $q->fetchArray();
print_r($categories);

Now code executed without exception, BUT $q->fetchArray() returned only ONE (first) record hydrated to array. Other results were ignored.

Let's change code one more time:

$q = Doctrine_Query::create ()
->select('c.id, c.path, c.name, cbc.product_count AS product_count')
->from('Category c')
->leftJoin('c.CategoryBrowserCache cbc');
$categories = $q->fetchArray();
print_r($categories);

Like you see I just removed all aliases for columns for Category. Now code will be executed without exceptions, All results will be hydrated into array as expected to be. Actually the same result can be reached by removing at least one alias for any Category column.






[DC-966] Default Order By incorrectly propagating to relations Created: 12/Feb/11  Updated: 12/Feb/11

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

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

Windows 7 WAMP, PHP 5.3, MySQL 5.1.36, Apache 2.2.11



 Description   

Symfony Version 1.4.9 ORM: Doctrine

Schema.yml:

Table1:
actAs:
Timestampable: ~
options:
orderBy: sort_order ASC
columns:
name:

{ string(255), notnull: true }

sort_order:

{ string(255), notnull: true }

Table2:
columns:
table1_id:

{ integer, notnull: true }

value:

{ string(255), notnull: true }

relations:
Table1:

{ local: table1_id, foreign: id, foreignAlias: Table2 }

This generates models and I can see the following: BaseTable?1.class.php: $this->option('sort_order', 'sort_order ASC');

BaseTable?2.class.php: No option for sort_order

But when I run the following, I get errors: Doctine::getTable('Table1')>createQuery('t')>leftJoin('t.Table2 t2').execute();

Error: Column not found: 1054 Unknown column 't2.sort_order' in 'order clause'

Looking at the sql executed, it included t1.sort_order ASC, but also incorrectly added t2.sort_order ASC as well even though it was never defined anywhere.

I am unsure if this is a Doctrine problem or a symfony one, so I will post i on both bug tracking systems.






[DC-961] Copy uses mutators but does not use accessors Created: 28/Jan/11  Updated: 28/Jan/11

Status: Open
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Paul Jones Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None


 Description   

I have a column that contains a serialized string of data. The accessor for that column unserializes the data and the mutator serializes. When calling copy the accessor is not used but the mutator is causing the mutator to fail because it receives a string instead of an object as its value.

The lines of code creating this problem follow:

Record.php
 public function copy($deep = false)
 {
    $data = $this->_data; //does not use accessor
...
    $ret = $this->_table->create($data); // does use mutator
...
}

I have currently patched my copy function with the following:

// $data = $this->_data
$data = $this->toArray(false);





[DC-960] Bug in OCI8 adapter's freeCursor function causes exception with HYDRATE_ON_DEMAND Created: 26/Jan/11  Updated: 17/Apr/14

Status: Open
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, 1.2.0-BETA2, 1.2.0-BETA3, 1.2.0-RC1, 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

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

doctrine, symfony, linux, hpux


Attachments: File closeCursor.diff    

 Description   

oci_free_statement should be changed to oci_cancel inside Doctrine_Adapter_Statement_Oracle::closeCursor(). Otherwise exception is thrown if HYDRATE_ON_DEMAND is used followed by foreach loop.

Doctrine2 should also be affected by this bug.

Change:
public function closeCursor()

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

To:
public function closeCursor()

{ $this->bindParams = array(); return oci_cancel($this->statement); }




Non-Equal Nest Relations Not Working - from "Children" side (DC-952)

[DC-958] updating Models with Intra-Table Relations cascades strangely Created: 24/Jan/11  Updated: 27/Jan/11

Status: Open
Project: Doctrine 1
Component/s: Behaviors, Documentation, Nested Set, Relations
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Daniel Reiche Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.3 / symfony 1.4.9



 Description   

Sorry for the lengthy explanation, couldn't make it more straight forward:

I have a model which is similiar to a nestet set but the tree structure needs to overlap:

For Model A, every Object A1 can have multiple descendant objects A2 and in turn can be a descendant of multiple objects A0.

Since I saw no way to do this with Nested-Set Relations (or Equal-Nested-Sets) I have set up my Model like this:

modules:
columns: ..<do not matter>
relations:
Children:
class: modules
refClass: modules_required
Parents:
class: modules
refClass: modules_required

modules_required:
columns: <do not matter here, just 2 foreign key columns>
relations:
Children:
Parents:

I needed to specify the Relations on both tables, to use onDelete/onUpdate CASCADE rules. Generated Models look fine, just as intended.
(Every Class has many Children and has many Parents...)

Now the strange part:
When I update an object of modules (say id=18), Doctrine issues the following queries:
DELETE FROM modules_required WHERE (required_id = ? AND module_id IN (?, ?, ?, ?, ?)) - (18, 25, 26, 32, 34, 35)
// where 25 to 35 are CHILDREN of 18
UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (25, 25, 10)
UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (26, 26, 10)
UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (32, 32, 10)
UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (34, 34, 10)
UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (35, 35, 10)
UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (25, 25, 12)
//where 10 and 12 are PARENTS of 18
and somewhen, Doctrine encounters an MySQL ERROR because of the previous update marathon:
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '25-25' for key 'PRIMARY'

The point is:
1. why is Doctrine trying to create self-referencing relations, and
2. why is it touching the relation at all, when i only did change some text fields in the object?

Is there a better way to solve my problem?



 Comments   
Comment by Daniel Reiche [ 25/Jan/11 ]

forgot to add something: I have done a debug run, to see why these queries are created, when there was no data modified that related to these tables:

Doctrine seems to handle my structure internally as a Nested-Set, although I have not specified an actAs: NestedSet or relations: equal: true statement in the model definition.
Is there a way to prevent symfony from misinterpreting this?

This is not a nested set, as each object can have virtually any other object either as parent or as a child, and additionaly, parent relations can span multiple tree-levels:
Object 2 is parent of Object 3 and 6
Object 3 is parent of Object 4 and 5
Object 4 is parent of Object 6

results in: Object 6 has parents 2 and 4 (where 4 has parent 3 and 3 has parent 2 in turn)

This spanning relations seems to cause the guessed nested set to fail.

I simply wanted to create an m:n Relation using a Reference table and the fact that both m and n are of the same class should not consider doctrine.

Comment by Daniel Reiche [ 26/Jan/11 ]

related to #DC-329:
seems to be the same general problem as described there. Only in DC 1.2.3, doctrine tries to delete every child-relation for some unknown reason.

also the h2aEqualable mentioned there does not work, because it does not prevent symfony from issueing the delete queries. It prevents only the UPDATE-Queries, and thus circumvents the MySQL-Error.

Nevertheless, data is still corrupted after object save, thus not useable in production.





[DC-957] MSSQL doctrine inner join group by problem Created: 20/Jan/11  Updated: 20/Jan/11

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

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

mssql, doctrine 1.2.3 , symfony



 Description   

http://www.doctrine-project.org/projects/orm/1.2/docs/manual/dql-doctrine-query-language/en#group-by,-having-clauses

$q = Doctrine_Query::create()
->select('u.username')
->addSelect('COUNT(p.id) as num_phonenumbers')
->from('User u')
->leftJoin('u.Phonenumbers p')
->groupBy('u.id');

SELECT
u.id AS u__id,
u.username AS u__username,
COUNT(p.id) AS p__0
FROM user u
LEFT JOIN phonenumber p ON u.id = p.user_id
GROUP BY u.id

i should create

SELECT
COUNT(p.id) AS p__0
FROM user u
LEFT JOIN phonenumber p ON u.id = p.user_id
GROUP BY u.id

MSSQL doesnt support this use of group by sql. Id have to be in aggregrate function or group by. I do not need id but doctrine creates it in sql.

"invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause."






[DC-956] Validation error (unique) when inserting an object with Searchable behavior Created: 20/Jan/11  Updated: 20/Jan/11

Status: Open
Project: Doctrine 1
Component/s: Searchable
Affects Version/s: 1.2.3
Fix Version/s: None

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

Ubuntu Linux with Apache 2 and PHP 5.3.



 Description   

As soon as one enables the Searchable behavior like the following it is not possible anymore to create or update an entity.

public function setTableDefinition()

Unknown macro: { $this->setTableName('seartest_article'); $this->hasColumn('articleid', 'integer', 11, array( 'type' => 'integer', 'primary' => true, 'autoincrement' => true, 'unsigned' => true, 'notnull' => false, 'unique' => true, 'length' => 11 ) ); $this->hasColumn('title', 'string', 255, array( 'type' => 'string', 'notnull' => false, 'length' => 255 ) ); $this->hasColumn('description', 'string', null, array( 'type' => 'string', 'notnull' => false, 'length' => null ) ); $this->option('type', 'INNODB'); $this->option('collate', 'utf8_unicode_ci'); $this->option('charset', 'utf8'); }

public function setUp()

Unknown macro: { // Search support $search = new Doctrine_Template_Searchable(array( 'fields' => array('title', 'description'), 'batchUpdate' => false ) ); $this->actAs($search); $this->addListener(new SearchableTest_Model_ArticleListener()); }

After trying to create a new item the following error message appears (note the record class is called SearchableTest_Model_Article and the primary id column is named articleid):

Validation failed in class SearchableTest_Model_ArticleIndex 1 field had validation error: * 1 validator failed on articleid (unique)






[DC-955] Loading fixtures containing data for Versionable/Searchable Models fails due to Duplicate-Key errors Created: 14/Jan/11  Updated: 14/Jan/11

Status: Open
Project: Doctrine 1
Component/s: Behaviors, Data Fixtures, Import/Export, Searchable
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Daniel Reiche Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

PHP 5.3.3 / symfony 1.4.9-dev / MySQL 5.0



 Description   

Sample schema:

Blog:
actAs: [Versionable, Searchable]
columns:
id:

{ type: integer, primary: true, autoincrement: true }

name: string
text: text

When dumping data of a schema with Versionable and/or Searchable Behaviour, the dump.yml will contain all data, including the *_version and *_index tables.

Trying to load the same .yml file results in Duplicate-Key constraint violations, as long as the data for the *_version and *_index tables is present.
The import is only successfull, when the data for these tables is discarded.
This leads to the issue, that one can only do a dump-load cycle, when the complete version history of a Model is discarded. Which makes dump-load for such models rather useless.






[DC-954] tinyint(1) with default value in schema.yml generates blank default value, gives SQLSTATE[42000] Created: 09/Jan/11  Updated: 09/Jan/11

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

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

Win7 64-bit
Netbeans 6.9.1
Symfony 1.4.8



 Description   

doing a
doctrine:build --all --and-load
with a schema.yml of

Foo:
tableName: foo
options:
charset: utf8
columns:
bar:
type: tinyint(1)
default: 0

results in a blank value generated for the default keyword, and the following error:

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 ENGINE = INNODB' at line 1. Failing Query: "CREATE TABLE foo (id BIGINT AUTO_INCREMENT, bar tinyint(1) DEFAULT , PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 ENGINE = INNODB". Failing Query: CREATE TABLE foo (id BIGINT AUTO_INCREMENT, bar tinyint(1) DEFAULT , PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 ENGINE = INNODB

I've also tried combinations of tinyint, tinyint(4), single-quoting the default value, and different default values.

Changing the type to int makes the issue disappear






[DC-953] Doctrine fails when using link() on OneToMany because of failing save Created: 04/Jan/11  Updated: 04/Jan/11

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

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

PHP 5.2.10, MySQL database connection


Attachments: File test.php     File test.yml    

 Description   

I have continually run into a very particular bug when using OneToMany relationships between Doctrine tables. When attempting to call "link()" to generate a relationship between records in related tables, Doctrine attempts to set the ID of the "one" portion of the record to 0, then save it.

This is best demonstrated by the sample YML and PHP that I have attached. It establishes a OneToMany relationship where the "one" table has another foreign key constraint. This causes the DB to trigger a foreign key constraint error when Doctrine tries to set the ID to 0, making the error easier to see.

From looking into the relevant sections of the codebase, the following appears to be happening:

  • Calling "link" properly adds the relationship to the "many" record.
  • Calling "save" triggers the saving of the "many" record and all associated records.
  • With the "one" record now listed as an associated record, its own "save" function is called as a result.
  • Its "save" function works properly, except that for some reason, the ID key is not present in the $_data internal array (but oddly is present in the $_id array, allowing it to be returned in other places).
  • Seeing a difference, Doctrine attempts to execute an "UPDATE" query setting the ID to 0.

I've made it this far in looking into it, but for the life of me I can't figure out what is triggering the identifier being reset in this case. I should note, however, that it happens consistently in every such situation on every server I've tested it on.



 Comments   
Comment by Buster Neece [ 04/Jan/11 ]

Further research into the issue has revealed the exact area where the problem is being caused:

Doctrine_Collection (272): Function "setReference", called from Doctrine_Relation_ForeignKey (80).

For each of the elements in the collection (in this case, the related items), that function is setting the "reference field" value to the record being related to. Apparently, it's getting the field names confused, because it's overwriting "id" with a reference to the entire related object, which has a different ID.

I can't tell if this is only an issue when both the relation tables use the same identifier ("id"), but this is surely common enough to warrant a fix.





[DC-951] Error in generating the field size and error in the generation of the date fields for postgres Created: 24/Dec/10  Updated: 17/Apr/14

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

Type: New Feature Priority: Major
Reporter: fernando guerrero Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

apacha2, linux, Symfony 1.4



 Description   

collaboration of vtamara@pasosdejesus.org and jeronimo0000@gmail.com

While we developed a tool with symfony 1.4 and postgresql database we found errors in the generated schema.yml which I describe below

1 - Error in generating of field size of varchars
2 - Error in the generation of date fields

We found the following solution

— Doctrine/Import/Pgsql.php.orig 2010-12-23 17:48:00.160271000 -0500
+++ Doctrine/Import/Pgsql.php 2010-12-23 18:01:59.252271002 -0500
@@ -168,11 +168,14 @@
$columns = array();
foreach ($result as $key => $val) {
$val = array_change_key_case($val, CASE_LOWER);

  • if (strtolower($val['type']) === 'character varying') {
    + if (strtolower($val['type']) === 'varchar') { // get length from varchar definition $length = preg_replace('~.*\(([0-9]*)\).*~', '$1', $val['complete_type']); $val['length'] = $length; }

    + if ($val['type'] == 'date')

    { + $val['type'] = $val['complete_type'] = 'timestamp'; + }

$decl = $this->conn->dataDict->getPortableDeclaration($val);






[DC-949] (patch)allow Native floats and double precision field types for MySQL, Oracle, Pgsql Created: 09/Dec/10  Updated: 09/Dec/10

Status: Open
Project: Doctrine 1
Component/s: Attributes
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Max Blackmer Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Os Independent, MySQL, Oracle, Postgresql


Attachments: Text File doctrine-1.2-native-float.patch    

 Description   

This creates a new attribute constant Doctrine_Core::ATTR_USE_NATIVE_FLOAT and Doctrine_Core::ATTR_USE_NATIVE_DOUBLE. This will allow the setting of attributes of use_native_float = true and use_native_double = true. With these set to true in MySQL of the generated sql will no longer Make FLOAT(18,2) and will make it just FLOAT that is a true floating point the same thing with DOUBLE except it is now a true double precision floating point.

Proper adjustments are also made to MySQL, Oracle and Postgresql to use native floating point declarations to define both single and double precision floating point data types.

I have attached a patch to fix the floating point field types.



 Comments   
Comment by Max Blackmer [ 09/Dec/10 ]

Quote from MySQL Manual "For maximum portability, code requiring storage of approximate numeric data values should use FLOAT or DOUBLE PRECISION with no specification of precision or number of digits" http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html





[DC-946] Oracle Doctrine_RawSql()->count() generates illegal SQL Created: 08/Dec/10  Updated: 06/Aug/12

Status: Open
Project: Doctrine 1
Component/s: Native SQL
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lars Pohlmann Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: oracle


 Description   

Example RawSQL:

$q = new Doctrine_RawSql();
    $q->select('{k.*}')
          ->from('SHP_MANDANT_KATEGORIE k')
          ->addComponent('k', 'ShpMandantKategorie k')
          ->where( 'k.id_mandant=' . $this->getIdMandant() )
          ->andWhere( 'k.id_parent=' . $this->getIdMandantkategorie() )
          ->andWhere( 'k.aktiv=1' )
          ->orderBy( 'k.sortorder' ); 

$q->count() generates:

SELECT COUNT(*) as num_results 
FROM (SELECT DISTINCT k.id_mandantkategorie 
              FROM SHP_MANDANT_KATEGORIE k 
              WHERE k.id_mandant=2 AND k.id_parent=1520 AND k.aktiv=1) as results

The illegal Part ist the "as results" at the end...



 Comments   
Comment by Lars Pohlmann [ 06/Aug/12 ]

Hi,

will this ever be corrected?
I just came across the same bug in another project...





[DC-944] Precedence problem in SQL generation allows bypass of pending joins Created: 03/Dec/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Walter Hop Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.2, 5.3


Attachments: File Query.pendingjoin.diff    

 Description   

'Pending join conditions' are used by listeners to inject extra SQL conditions into a query. They are often used to add basic constraints on every query. An example is the bundled SoftDelete template. Its listener adds extra constraints such as s.deleted_at IS NULL to a query, to make sure that deleted rows are never retrieved on a query.

However, in the emitted SQL, Doctrine_Query does not use parentheses to group normal SQL conditions together. The pending join condition is simply added to the string without encapsulating existing expressions. This makes it possible to bypass the pending join conditions entirely by using the OR operator.

Example

For instance, the following query exhibits this problem:

$query = Doctrine_Query::create()
->from("SoftDeleteTest")
->where("name=?", "faulty")
->orWhere("name=?", "faulty");

This query emits the following SQL:

SELECT s.name AS s_name, s.deleted_at AS s_deleted_at FROM soft_delete_test s WHERE (s.name = 'faulty' OR s.name = 'faulty' AND (s.deleted_at IS NULL))

which returns also a deleted row.

Expected behavior

One would expect the pending join conditions always to hold, and to have precedence over regularly added SQL conditions. This could be accomplished in the most simple fashion by:

SELECT s.name AS s_name, s.deleted_at AS s_deleted_at FROM soft_delete_test s WHERE ( ( s.name = 'faulty' OR s.name = 'faulty' ) AND (s.deleted_at IS NULL));

As the existing expressions are now encapsulated by parentheses, it is no longer possible to bypass the pending join conditions injected by the query listener.

Full test case details:

init.sql

create database softdelete;
grant all privileges on softdelete.* to softdelete@localhost identified by 'uahwqeruwer';

use softdelete;
CREATE TABLE soft_delete_test (name VARCHAR(255), 
    deleted_at DATETIME DEFAULT NULL, 
    PRIMARY KEY(name)) ENGINE = INNODB;

insert into soft_delete_test values ('fine', null);
insert into soft_delete_test values ('faulty', now());

run.php

<?php

require "./1.2.3/lib/Doctrine.php";

spl_autoload_register(array('Doctrine', 'autoload'));

require "SoftDeleteTest.php";

$conn = Doctrine_Manager::connection("mysql://softdelete:uahwqeruwer@localhost/softdelete");
$conn->setAttribute(Doctrine::ATTR_USE_DQL_CALLBACKS, true);

$query = Doctrine_Query::create()
    ->from("SoftDeleteTest")
    ->where("name=?", "faulty")
    ->orWhere("name=?", "faulty");

$found = $query->execute();
foreach ($found as $f) {
    echo "ERROR! Found a deleted row: $f->name\n";
}
echo "Done.\n";

SoftDeleteTest.php (copied from Doctrine manual)

<?php

class SoftDeleteTest extends Doctrine_Record
{
    public function setTableDefinition()
    {
        $this->hasColumn('name', 'string', null, array(
                'primary' => true
            )
        );
    }

    public function setUp()
    {
        $this->actAs('SoftDelete');
    }
}


 Comments   
Comment by Walter Hop [ 03/Dec/10 ]

Fixing quote formatting

Comment by Walter Hop [ 03/Dec/10 ]

Final formatting fixes.





[DC-942] fromArray makes unnessesary cals to database Created: 03/Dec/10  Updated: 03/Dec/10

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

Type: Bug Priority: Major
Reporter: Ivo Võsa Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If I do toArray(true) on record with realtions and later fromArray($array, true) on with same data unnessesary calls to database are made.

$message = new Message();
$message->Sender = new User(); // if i leave out this line sender will first get loaded from database and then overwritten with provided data
$message->Receiver = new User();   // if i leave out this line receiver will first get loaded from database and then overwritten with provided data
$message->fromArray($data);

In Doctrine_Record::fromArray()

if ($deep && $this->getTable()->hasRelation($key)) {
    if ( ! $this->$key) {                                           --> data gets loaded from db here, refreshRelated is not even executed.
        $this->refreshRelated($key);
    }
...
}

Is this desired behavour? Wouldnt it be smarter to create empty object automaticly instead of loading it from db?
Also have look at http://trac.doctrine-project.org/ticket/1434






[DC-941] Spatial index type for mysql Created: 29/Nov/10  Updated: 29/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: 1.2.3

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

Attachments: Text File patch.patch    

 Description   

I'm using doctrine and some of mysql's spatial functions. I need to specify spatial index for my tables.
My declaration looks like:

Geometry:
tableName: geometry
options:
type: MyISAM
collate: utf8_unicode_ci
charset: utf8
columns:
id:
type: integer(4)
primary: true
autoincrement: true
geometry:
type: geometry
notnull: true
indexes:
geometry:
fields:

  • geometry
    type: spatial

Exporting this definitions throws an exception: Unknown type spatial for index geometry_idx






[DC-940] Doctrine - loading a YAML fixture with French characters, replaces the accents with junk Created: 26/Nov/10  Updated: 26/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures
Affects Version/s: 1.2.3
Fix Version/s: None

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

MAC OS X (10.6.5)
MAMP 1.9.4
PHP 5.3.2



 Description   

Hi,

My Doctrine 1.2 is integrated inside CodeIgniter as a hook and I know that my char-set is utf8 with collation utf8_unicode_ci.

I have two YAML files, one for creating the DB and its tables and one to load some test data. My data can contain French accents (çéïë...). In my schama.yml I have correctly specified the collation and char-set:

options:
type: INNODB
charset: utf8
collate: utf8_unicode_ci

I double checked the settings in phpMyAdmin, everything is correct.

When I run my doctrine script from commandline to load my fixture to populate one of tables, all the French accents are replaced by junk!

Am I missing a setting or configuration or is there a bug in Doctrine?

I appreciate any help. Cheers.

P.S. Everything else works like a charm






[DC-939] Patch for Doctrine ..... to identify in some cases autoincremented fields in oracle Created: 25/Nov/10  Updated: 24/Dec/10

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

Type: Bug Priority: Major
Reporter: Edwin Alexander Herrera Saavedra Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP Version 5.2.4-2ubuntu5.10
Copyright (c) 1997-2007 The PHP Group
Oracle database 10gR2
Symfony 1.4.4



 Description   

Patch for Doctrine ..... to identify in some cases autoincremented
fields.
[Solution found thanks to Vladimir Tamara - vtamara AT pasosdejesus DOT org]

Doctrine/Import/Oracle.php

// Heuristic to check autoincremented fields.
// We check if there is a trigger on the field.
// We could also check if there is a sequence on the field.
// Side effect: slower generation of scheme
$q = "SELECT * FROM all_trigger_cols WHERE
table_name='$table' AND column_name='" . $val['column_name'];

$res2 = $this->conn->fetchColumn($q);
if (count($res2) > 0)

{ $descr[$val['column_name']]['autoincrement'] = true; }

}

return $descr;



 Comments   
Comment by Edwin Alexander Herrera Saavedra [ 24/Dec/10 ]

when new tables are created, the auto-increment is shown in all fields of the table in the schema, to avoid this problem has generated the following improvements to a validation of the auto-increment column is only when the primary key

Solution found thanks to
Vladimir Tamara - vtamara AT pasosdejesus DOT org
and Alexander Herrera

if($descr[$val['column_name']]['primary']==1){
// Heuristic to check autoincremented fields.
// We check if there is a trigger on the field.
// We could also check if there is a sequence on the field.
// Side effect: slower generation of scheme
//SELECT * FROM ALL_CONS_COLUMNS WHERE CONSTRAINT_NAME LIKE '%TS_DIS_REG_PK%' AND COLUMN_NAME='FECHA_PROC';
$q="SELECT * FROM ALL_CONS_COLUMNS WHERE CONSTRAINT_NAME LIKE '%".$table."_PK%' AND COLUMN_NAME='".$val['column_name']."'

";
// echo $descr[$val['column_name']]['primary']."\n";
$s = "SELECT * FROM all_trigger_cols WHERE table_name='$table' AND column_name='" . $val['column_name'] . "'";
//echo $q."\n";
$res2 = $this->conn->fetchColumn($q);
$res3 = $this->conn->fetchColumn($s);
if (count($res2) > 0 && count($res3)>0)

{ $descr[$val['column_name']]['autoincrement'] = true; }

}





[DC-938] Impossible to use other formats than YAML in data import Created: 25/Nov/10  Updated: 25/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures
Affects Version/s: 1.2.3
Fix Version/s: None

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


 Description   

File Doctrine/Data/Import.php, line #80
if (end($e) == 'yml')

So, if the file is a .json (for exemple), it will be impossible to load it, even if we have specified "json" as format parameter.
And it sucks.

The fix would just be to change the line to :
if (end($e) == $this->getFormat())






[DC-937] Cross Schema stored procedures are not recognized Created: 22/Nov/10  Updated: 08/Dec/10

Status: Open
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: will ferrer Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

XP Xamp


Attachments: Text File DC_937_fix.patch    

 Description   

When you call a stored procedure from a schema other than that of the current connection: [schema_name].[stored_procedure_name]([stored_procedure_arguments]) doctrine miss understands the string and throws a "Couldn't get short alias for" exception.

I fixed this by adding some more regex to the getExpressionOwner method of the Query Class.

I will post the patch shortly.

Will Ferrer



 Comments   
Comment by will ferrer [ 08/Dec/10 ]

Fixed an issue where the code wouldn't work with calls to stored procedure that were nestted in groups in selects.





[DC-936] json schema import broken Created: 22/Nov/10  Updated: 22/Dec/10

Status: Open
Project: Doctrine 1
Component/s: File Parser
Affects Version/s: 1.2.3
Fix Version/s: None

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

PHP 5.3.3-1ubuntu9.1


Attachments: File foobar.schema.json    

 Description   

With a valid Json file :
PHP Warning: explode() expects parameter 2 to be string, object given in Doctrine/Doctrine/Import/Schema.php on line 381
PHP Catchable fatal error: Object of class stdClass could not be converted to string in Doctrine/Doctrine/Import/Schema.php on line 391

It's due to this line, line, in Doctrine/Parser/Json.php (#65) :
$json = json_decode($contents);

It should be:
$json = json_decode($contents, true);

Because casting the result as array will only affect the top-level element. You must use the second parameter of json_decode() to force every objects (including sub-objects) to be converted to indexed arrays.



 Comments   
Comment by Mael Nison [ 22/Nov/10 ]

A try to import this file should fail.

Comment by Brian Fenton [ 22/Dec/10 ]

I've submitted a pull request w/patch and unit test for this issue using the fix above. I had the same problem in my code on OS X 10.6.4, PHP 5.3.2





[DC-935] Doctrine_Task_BuildAllReload does not call generate-models-from-yaml Created: 21/Nov/10  Updated: 21/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Cli
Affects Version/s: 1.2.3
Fix Version/s: None

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

Windows Vista 32bit, Apache 2.2.14, PHP 5.3.1


Attachments: Text File DC-935.patch    

 Description   

Doctrine_Task_BuildAllReload never calls generate models-from-yaml. This does not coincide with the logic of Doctrine_Task_BuildAll and Doctrine_Task_BuildAllLoad.

BuildAllReload suggests that it will be building all (everything) and then reloading the database.
But instead it only rebuilds the database and loads data

Doctrine 1.2.3 - BuildAllReload.php
public function __construct($dispatcher = null)
    {
        parent::__construct($dispatcher);

        $this->rebuildDb = new Doctrine_Task_RebuildDb($this->dispatcher);
        $this->loadData = new Doctrine_Task_LoadData($this->dispatcher);
        
        $this->requiredArguments = array_merge($this->requiredArguments, $this->rebuildDb->requiredArguments, $this->loadData->requiredArguments);
        $this->optionalArguments = array_merge($this->optionalArguments, $this->rebuildDb->optionalArguments, $this->loadData->optionalArguments);
    }
    
    public function execute()
    {
        $this->rebuildDb->setArguments($this->getArguments());
        $this->rebuildDb->execute();
        
        $this->loadData->setArguments($this->getArguments());
        $this->loadData->execute();
    }

Instead, I think it would be more efficient and understanding to follow the same logic as build-all and build-all-load by calling drop-db and build-all-load.

Proposed - BuildAllReload.php
public function __construct($dispatcher = null)
    {
        parent::__construct($dispatcher);

        $this->dropDb = new Doctrine_Task_DropDb($this->dispatcher);
        
        $this->buildAllLoad = new Doctrine_Task_BuildAllLoad($this->dispatcher);
        
        $this->requiredArguments = array_merge($this->requiredArguments, $this->dropDb->requiredArguments, $this->buildAllLoad->requiredArguments);
        $this->optionalArguments = array_merge($this->optionalArguments, $this->dropDb->optionalArguments, $this->buildAllLoad->optionalArguments);
    }
    
    public function execute()
    {
        $this->dropDb->setArguments($this->getArguments());
        $this->dropDb->execute();
        
        $this->buildAllLoad->setArguments($this->getArguments());
        $this->buildAllLoad->execute();
    }

I attached a patch with the above changes... I got a little lost in the test area for Doctrine_CLI, so that is not included = )



 Comments   
Comment by Brandon Evans [ 21/Nov/10 ]

Added the proper proposed code this time and also attached patch with better naming.





[DC-934] One-to-one relationship with cascading deletion and softdelete creates empty records Created: 21/Nov/10  Updated: 29/Nov/11

Status: Open
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Rich Sage Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Ubuntu 10.10, PHP 5.3.3


Attachments: File testcase.php    

 Description   

When using softdelete behaviour with cascading deletion on a one-to-one relationship, Doctrine will create a 'child' record if it doesn't exist already, during the cascading deletion. Eg:

  • Models Foo, Bar, both SoftDelete
  • Foo hasOne Bar
  • $myFoo->delete()

Result is:

  • $myFoo->deleted_at is set correctly as expected
  • New Bar record is created & saved in the process (but is not set to deleted)

Is this expected behaviour? I've attached a test case script, tested against export from SVN of Doctrine 1.2.3 that demonstrates this.



 Comments   
Comment by marius [ 29/Nov/11 ]

I can confirm this issue on Ubuntu 11.10 PHP 5.3.6-13ubuntu3.2





[DC-931] Newly generated Migration Classes failing to load due to method used to determine class name Created: 19/Nov/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.0-ALPHA1, 1.2.0-ALPHA2, 1.2.0-ALPHA3, 1.2.0-BETA1, 1.2.0-BETA2, 1.2.0-BETA3, 1.2.0-RC1, 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

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

LAMP



 Description   

The loadMigrationClassesFromDirectory() method in Doctrine_Migration uses array_diff on get_declared_classes() between including each classes script.

When a new migration class is generated by Doctrine_Core::generateMigrationsFromDiff it's class is loaded, which means loadMigrationClassesFromDirectory silently fails to load the newly generated migration on the same request. This means that scripts that first generate migrations and then apply them must be executed twice - first to generate then to apply.

The following example code is used to check if the database has been modifed, generate migrations between the base version and the latest models, and then migrate the database if needed:

automigrate.php
Doctrine_Core::generateYamlFromModels(ROOT_PATH.'tmp/yaml/', ROOT_PATH.'models/');
$result = Doctrine_Core::generateMigrationsFromDiff(ROOT_PATH.'tmp/migrations/', ROOT_PATH.'data/yaml/', ROOT_PATH.'tmp/yaml/');

unlink(ROOT_PATH.'data/yaml/schema.yml');
rename(ROOT_PATH.'tmp/yaml/schema.yml', ROOT_PATH.'data/yaml/schema.yml');

$migration = new Doctrine_Migration(ROOT_PATH.'tmp/migrations');

$currentVersion = $migration->getCurrentVersion();
$latestVersion = $migration->getLatestVersion();
if ($currentVersion < $latestVersion) {
	$migration->migrate();
	$this->app->addMessage("Database migration completed (from version $currentVersion to version $latestVersion)","success");
} else {
	$this->app->addMessage("Database is up to date and doesn't require migration (at version $currentVersion)","success");
}






[DC-930] Complex query with DISTINCT and LIMIT on pgsql causes a SQLSTATE exception - problem in doctrine_subquery_alias Created: 16/Nov/10  Updated: 16/Nov/10

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

Type: Bug Priority: Major
Reporter: Jacek Dębowczyk Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

pgsql



 Description   

There is a problem in the following code in Doctrine/Query.php (lines 1257-1279) inside the buildSqlQuery() method:

            $subquery = $this->getLimitSubquery();

            // what about composite keys?
            $idColumnName = $table->getColumnName($table->getIdentifier());

            switch (strtolower($this->_conn->getDriverName())) {
                case 'mysql':
[...]
                case 'pgsql':
                    $subqueryAlias = $this->_conn->quoteIdentifier('doctrine_subquery_alias');

                    // pgsql needs special nested LIMIT subquery
                    $subquery = 'SELECT ' . $subqueryAlias . '.' . $this->_conn->quoteIdentifier($idColumnName)
                            . ' FROM (' . $subquery . ') AS ' . $subqueryAlias;

                    break;
            }

The above code is executed when a query consist of DISTINCT and LIMIT clauses. The most common situation is using pager.
The problem is in the subquery variable. The $idColumnName variable often has value "id". In such a situation in case of $subquery consist of some JOINs and some tables have column named "id", we have:

SELECT doctrine_subquery_alias.id FROM ((SELECT DISTINCT d1.id, d2.id FROM ...)) AS doctrine_subquery_alias

It, of course, causes the "ambiguous column name" pgsql exception.






[DC-929] createIndexSql and dropIndexSql don't use the same logic to get the index name Created: 16/Nov/10  Updated: 07/Sep/11

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

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

Postgresql 8.4, Symfony 1.4, Doctrine 1.2



 Description   

In the class Doctrine_Export the functions for creating and dropping indexes do not use the same logic to get the name of the index to be created or dropped.
When creating an index $this->conn->quoteIdentifier() is called on the index name.
When dropping an index $this->conn->quoteIdentifier($this->conn->formatter->getIndexName()) is called on the name, which by default adds '_idx' to the index name. Hence, when an index should be dropped in a migration an index with that name is not found because it was created without the '_idx'.



 Comments   
Comment by Lukas Kahwe [ 16/Nov/10 ]

looks to me like this is a bug in index creation. then again fixing the bug will lead to potential BC issues. that being said, anyone affected could "simply" set the index format to empty. also "fixing" the names to the proper format does not require shuffeling around data. so imho the right fix would be to apply the drop naming logic in the create logic.

what surprises me is that the main reason for appending _idx by default was that many RDBMS will otherwise break because they do not separate identifiers between constraints and indexes etc and therefore people run into collisions without the postfix.

Comment by John Kary [ 07/Sep/11 ]

Related/Duplicate of DC-830 and DC-867.





[DC-928] [Migrations] Drop not null is not working in Postgres Created: 16/Nov/10  Updated: 16/Nov/10

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

Type: Bug Priority: Major
Reporter: Lea Haensenberger Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Postgresql 8.4, Symfony 1.4, Doctrine 1.2


Attachments: Text File dropNotNullPatch.patch    

 Description   

When removing the not null from a column the migration does not change anything in the database. This is due to the following check on line 162 of lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Export/Pgsql.php
if ( ! empty($field['definition']['notnull']))

So if notnull is not there or set to false or '0' or 0 the code does not enter into that if statement and therefore no changes are done to the not null value of the column.



 Comments   
Comment by Lukas Kahwe [ 16/Nov/10 ]

@Lea: can you write up a patch for this? would also be nice if you could check if the same issue affects other drivers.

Comment by Lea Haensenberger [ 16/Nov/10 ]

Here is a patch (attachment). The generate-migrations-diff Task in Symfony sets 'notnull' to an empty string if it's false in the schema.yml, therefore the check for empty string.

I had a quick look at the classes for other DBs, but that seems to be a postgres only issue.





[DC-927] Query with left join and group clause returns only one row, even though there are multiple results Created: 14/Nov/10  Updated: 19/May/11

Status: Open
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bart van den Burg Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 4
Labels: None
Environment:

Windows 7-64 bit
Symfony 1.4.8



 Description   

under certain circumstances, Doctrine will only return one result out of a bunch of results, for example:

$ symfony doctrine:dql "from Tafel t, t.Reservering r where t.restaurant_id=4 select date(t.tijd), count(t.id) tafels, count(r.id) reserveringen group by date(t.tijd)"
>> doctrine executing dql query
DQL: from Tafel t, t.Reservering r where t.restaurant_id=4 select date(t.tijd), count(t.id) tafels, count(r.id) reserveringen group by date(t.tijd)
found 2 results
-
date: '2010-11-14'
tafels: '1'
reserveringen: '1'

Expected outcome:
found 2 results
-
date: '2010-11-14'
tafels: '1'
reserveringen: '1'
-
date: '2010-11-16'
tafels: '1'
reserveringen: '0'

The query works fine without the left join:
$ symfony doctrine:dql "from Tafel t where t.restaurant_id=4 select date(t.tijd), count(t.id) tafels group by date(t.tijd)"
>> doctrine executing dql query
DQL: from Tafel t where t.restaurant_id=4 select date(t.tijd), count(t.id) tafels, group by date(t.tijd)
found 2 results
-
date: '2010-11-14'
tafels: '1'
-
date: '2010-11-16'
tafels: '1'



 Comments   
Comment by Bart van den Burg [ 14/Nov/10 ]

As you can see, by the way, it does actually say "found 2 results", but then returns only one.

Comment by Willem van Duijn [ 08/Feb/11 ]

There are multiple reports from people that are hurt by this bug:

http://www.devcomments.com/doctrine-execute-only-returns-one-row-to286270.htm
http://www.devcomments.com/Problem-with-Doctrine-and-Join-GroupBy-query-at87536.htm

Setting the Hydration-mode to HYDRATE_NONE yields multiple result rows (but is not useful).

Comment by Victor Ruiz [ 18/Feb/11 ]

Related in some way with multiple order by clauses. If I remove all of them but one it works, the problem appears when I put more than one order by criteria.

Comment by Mike Seth [ 19/May/11 ]

This is a hydration problem that occurs because the ID columns of the joined tables are not SELECT'ed explicitly. The offending code is a loop in the graph base hydrator, but I don't understand it well enough to fix it with any certainty that I don't break anything.





[DC-925] missing hasOne() method-call in many-to-many relation Created: 11/Nov/10  Updated: 11/Nov/10

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

Type: Bug Priority: Major
Reporter: Simon Schick Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Debian Lenny
Apache 2.0
PHP 5.3.3-0.dotdeb.1
Symfony 1.4.8 - using Doctrine 1.2.x



 Description   

Here's my YAML-file for the model: http://pastie.org/1290649

I'm using the following command to build the whole model: symfony doctrine:build --all --and-load
By this command symfony will create the model using Doctrine.

Please have a closer look at the class BaseTicketHasHardware: http://pastie.org/1290737
If I compare it to the class BaseTicketHasNote I expect a class like this: http://pastie.org/1290765
But Doctrine has created this class: http://pastie.org/1290766






[DC-924] type mismatch for keyfield in column aggregation Created: 11/Nov/10  Updated: 11/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Inheritance
Affects Version/s: 1.2.3
Fix Version/s: 1.2.3

Type: Bug Priority: Major
Reporter: Arnaud Morvan Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PostgreSQL



 Description   

This is the doc exemple on column aggregation inheritance :

Entity:
columns:
username: string(20)
password: string(16)
created_at: timestamp
updated_at: timestamp

User:
inheritance:
extends: Entity
type: column_aggregation
keyField: type
keyValue: 1

Group:
inheritance:
extends: Entity
type: column_aggregation
keyField: type
keyValue: 2

But the keyField (type) is created as VARCHAR(255) so PostgreSQL return an error on applying inheritance condition :

SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: character varying = integer
LINE 1: ...D s.application = 'frontend' AND s.lft = 1) AND (s.type = 2)
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.

I found this with symfony sfFilebasePlugin on sfFilebase:create-root task.






[DC-921] The ability to add WITH ROLLUP to a group by in a query Created: 09/Nov/10  Updated: 18/Nov/10

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

Type: New Feature Priority: Major
Reporter: will ferrer Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

XP XAMP



 Description   

I figured it would be handy to have a WITH ROLLUP be add able to the group by clause.

I added this feature but I can't post the patch because my patches are starting to run together - the syntax with in the generated patch would also contain parts of other patches I have posted to jira but have not yet been included in the doctrine svn.

I still wanted to make this post because it will give me a ticket number to base my test cases around.

Will Ferrer



 Comments   
Comment by will ferrer [ 09/Nov/10 ]

In order to illustrate what this patch fixes I am posting my test case for the patch below

<?php
/*
 *  $Id$
 *
 * 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.doctrine-project.org>.
 */

/**
 * Doctrine_Ticket_DC921_TestCase
 *
 * @package     Doctrine
 * @author      Will Ferrer
 * @license     http://www.opensource.org/licenses/lgpl-license.php LGPL
 * @category    Object Relational Mapping
 * @link        www.doctrine-project.org
 * @since       1.0
 * @version     $Revision$
 */
class Doctrine_Ticket_DC921_TestCase extends Doctrine_UnitTestCase 
{
  
    public function testAggregateValueMappingSupportsLeftJoinsWithRollUp()
    {
        $q = new Doctrine_Query();

        $q->select('MAX(u.name), u.*, p.*')->from('User u')->leftJoin('u.Phonenumber p')->groupby('u.id');
		$q->setWithRollUp(true);
        $this->assertEqual($q->getSqlQuery(), 'SELECT e.id AS e__id, e.name AS e__name, e.loginname AS e__loginname, e.password AS e__password, e.type AS e__type, e.created AS e__created, e.updated AS e__updated, e.email_id AS e__email_id, p.id AS p__id, p.phonenumber AS p__phonenumber, p.entity_id AS p__entity_id, MAX(e.name) AS e__0 FROM entity e LEFT JOIN phonenumber p ON e.id = p.entity_id WHERE (e.type = 0) GROUP BY e.id WITH ROLLUP');
    }

}
Comment by will ferrer [ 18/Nov/10 ]

I have updated my implemenation of this feature. Here is the new test case:

<?php
/*
 *  $Id$
 *
 * 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.doctrine-project.org>.
 */

/**
 * Doctrine_Ticket_DC921_TestCase
 *
 * @package     Doctrine
 * @author      Will Ferrer
 * @license     http://www.opensource.org/licenses/lgpl-license.php LGPL
 * @category    Object Relational Mapping
 * @link        www.doctrine-project.org
 * @since       1.0
 * @version     $Revision$
 */
class Doctrine_Ticket_DC921_TestCase extends Doctrine_UnitTestCase 
{
  
    public function testAggregateValueMappingSupportsLeftJoinsWithRollUp()
    {
        $q = new Doctrine_Query();

        $q->select('MAX(u.name), u.*, p.*')->from('User u')->leftJoin('u.Phonenumber p')->groupby('u.id');
		$q->withRollUp();
        $this->assertEqual($q->getSqlQuery(), 'SELECT e.id AS e__id, e.name AS e__name, e.loginname AS e__loginname, e.password AS e__password, e.type AS e__type, e.created AS e__created, e.updated AS e__updated, e.email_id AS e__email_id, p.id AS p__id, p.phonenumber AS p__phonenumber, p.entity_id AS p__entity_id, MAX(e.name) AS e__0 FROM entity e LEFT JOIN phonenumber p ON e.id = p.entity_id WHERE (e.type = 0) GROUP BY e.id WITH ROLLUP');
        $this->assertEqual($q->getDql(), 'SELECT MAX(u.name), u.*, p.* FROM User u LEFT JOIN u.Phonenumber p GROUP BY u.id WITH ROLLUP');
    }
	
	public function testAggregateValueMappingSupportsLeftJoinsWithRollUpDql()
    {
        $q = new Doctrine_Query();
        $q->parseDqlQuery("SELECT MAX(u.name), u.*, p.* FROM User u LEFT JOIN u.Phonenumber p GROUP BY u.id WITH ROLLUP");
        $this->assertEqual($q->getSqlQuery(), 'SELECT e.id AS e__id, e.name AS e__name, e.loginname AS e__loginname, e.password AS e__password, e.type AS e__type, e.created AS e__created, e.updated AS e__updated, e.email_id AS e__email_id, p.id AS p__id, p.phonenumber AS p__phonenumber, p.entity_id AS p__entity_id, MAX(e.name) AS e__0 FROM entity e LEFT JOIN phonenumber p ON e.id = p.entity_id WHERE (e.type = 0) GROUP BY e.id WITH ROLLUP');
        $this->assertEqual($q->getDql(), 'SELECT MAX(u.name), u.*, p.* FROM User u LEFT JOIN u.Phonenumber p GROUP BY u.id WITH ROLLUP');
    }
	
	


}




[DC-920] The ability to add sql in the query between the first word and body of the query (allowing "SELECT STRAIGHT_JOIN" etc) Created: 09/Nov/10  Updated: 09/Nov/10

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

Type: New Feature Priority: Major
Reporter: will ferrer Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

XP XAMP



 Description   

I recently discovered that I could greatly optimize some of the queries that were being run through our system by adding a STRAIGHT_JOIN keyword to the front of the select

I added a feature to doctrine which allows me to inject sql into the query in the right place to enable features such as "STRAIGHT_JOIN" but I can't post the patch because my patches are starting to run together – the syntax with in the generated patch would also contain parts of other patches I have posted to jira but have not yet been included in the doctrine svn.

I still wanted to make this post because it will give me a ticket number to base my test cases around.

Will Ferrer



 Comments   
Comment by will ferrer [ 09/Nov/10 ]

In order to show what this patch fixes I am including my test case for the patch below:

<?php
/*
 *  $Id$
 *
 * 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.doctrine-project.org>.
 */

/**
 * Doctrine_Ticket_DC920_TestCase
 *
 * @package     Doctrine
 * @author      Will Ferrer
 * @license     http://www.opensource.org/licenses/lgpl-license.php LGPL
 * @category    Object Relational Mapping
 * @link        www.doctrine-project.org
 * @since       1.0
 * @version     $Revision$
 */
class Doctrine_Ticket_DC920_TestCase extends Doctrine_UnitTestCase 
{

    public function testBeforeBodySelect()
    {
        $q = new Doctrine_Query();
        
        $q->parseDqlQuery("SELECT DISTINCT STRAIGHT_JOIN u.name, p.id FROM User u LEFT JOIN u.Phonenumber p ON p.phonenumber = '123 123'");
		$this->assertEqual($q->getSqlQuery(), "SELECT DISTINCT STRAIGHT_JOIN e.id AS e__id, e.name AS e__name, p.id AS p__id FROM entity e LEFT JOIN phonenumber p ON (p.phonenumber = '123 123') WHERE (e.type = 0)");
        $this->assertEqual($q->getDql(), "SELECT DISTINCT STRAIGHT_JOIN u.name, p.id FROM User u LEFT JOIN u.Phonenumber p ON p.phonenumber = '123 123'");
    }

	public function testBeforeBodySelectNoneDQL() 
    {
        $q = new Doctrine_Query();
        $q->select("DISTINCT STRAIGHT_JOIN u.name, p.id");
		$q->from('User u');
		$q->leftJoin("u.Phonenumber p ON (p.phonenumber = '123 123')");
        $this->assertEqual($q->getSqlQuery(), "SELECT DISTINCT STRAIGHT_JOIN e.id AS e__id, e.name AS e__name, p.id AS p__id FROM entity e LEFT JOIN phonenumber p ON (p.phonenumber = '123 123') WHERE (e.type = 0)");
        $this->assertEqual($q->getDql(), "SELECT DISTINCT STRAIGHT_JOIN u.name, p.id FROM User u LEFT JOIN u.Phonenumber p ON (p.phonenumber = '123 123')");
	}
	
    public function testBeforeBodyDelete() 
    {
        $q = new Doctrine_Query();

        $q->parseDqlQuery('DELETE IGNORE FROM User');
        $this->assertEqual($q->getSqlQuery(), 'DELETE IGNORE FROM entity WHERE (type = 0)');
        $this->assertEqual($q->getDql(), "DELETE IGNORE FROM User");
    }
	
	public function testBeforeBodyDeleteNoneDQL() 
    {
        $q = new Doctrine_Query();
        $q->delete('IGNORE');
		$q->from('User');
        $this->assertEqual($q->getSqlQuery(), 'DELETE IGNORE FROM entity WHERE (type = 0)');
        $this->assertEqual($q->getDql(), "DELETE IGNORE FROM User");
    }
	
	public function testBeforeBodyUpdate() 
    {
        $q = new Doctrine_Query();

        $q->parseDqlQuery("UPDATE IGNORE User u SET u.name = 'someone'");
        $this->assertEqual($q->getSqlQuery(), "UPDATE IGNORE entity SET name = 'someone' WHERE (type = 0)");
        $this->assertEqual($q->getDql(), "UPDATE IGNORE User u SET u.name = 'someone'");
    }
	
	public function testBeforeBodyUpdateNonDql() 
    {
        $q = new Doctrine_Query();
        $q->update('IGNORE');
		$q->from('User u');
		$q->set('name', "'someone'");
        $this->assertEqual($q->getSqlQuery(), "UPDATE IGNORE entity SET name = 'someone' WHERE (type = 0)");
        $this->assertEqual($q->getDql(), "UPDATE IGNORE User u SET name = 'someone'");
    }

}





[DC-919] Import/Pgsql.php: listTableColumns - SQL failure with PostgreSQL Created: 07/Nov/10  Updated: 09/Apr/12

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christian Vogel Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 4
Labels: None
Environment:

Postgres Import Schema


Attachments: File trac_9152_patch_for_Pgsql.php.diff    

 Description   

Hi,

this issue was reported at the symfony project which uses Doctrine 1.2.3:
http://trac.symfony-project.org/ticket/9152
"php symfony doctrine:build-schema failure with PostgreSQL for 1.4.7 and 1.4.8 version"

The SQL Statement 'listTableColumns' fails with an SQL-Error "missing from-clause"
http://trac.doctrine-project.org/browser/tags/1.2.3/lib/Doctrine/Import/Pgsql.php#L96
I can reproduce the error directly in psql or pgadmin. The SQL Statement seems related to DC-697

Even when i turn on the add_missing_from option on the postgres-server it fails with "missing relation".

Now it seems to me, you already fixed this bug in the current 1.2 branch, because the current SQL-Statement is different and it works for me in psql/pgadmin.
http://trac.doctrine-project.org/browser/branches/1.2/lib/Doctrine/Import/Pgsql.php#L96

Could you please close this ticket, if you already fixed this issue, or confirm if it's still an issue?
Attached you find my proposed patch at the symfony project . the current statement in the branch looks too different from my version, so i am not sure to use this patch directly. Tell me if I should work out a proper patch.

error
SQLSTATE[42P01]: Undefined table: 7 ERROR:  missing FROM-clause entry for table "t"                                               
 	  LINE 6: ...                                                  t.typtype ...                                                       
 	                                                               ^. Failing Query: "SELECT                                           
 	                                                       ordinal_position as attnum,                                                 
 	                                                       column_name as field,                                                       
 	                                                       udt_name as type,                                                           
 	                                                       data_type as complete_type,                                                 
 	                                                       t.typtype AS typtype,                                                       
 	                                                       is_nullable as isnotnull,                                                   
 	                                                       column_default as default,                                                   
 	                                                       (                                                                           
 	                                                         SELECT 't'                                                                 
 	                                                           FROM pg_index, pg_attribute a, pg_class c, pg_type t                     
 	                                                           WHERE c.relname = table_name AND a.attname = column_name                 
 	                                                           AND a.attnum > 0 AND a.attrelid = c.oid AND a.atttypid = t.oid           
 	                                                           AND c.oid = pg_index.indrelid AND a.attnum = ANY (pg_index.indkey)       
 	                                                           AND pg_index.indisprimary = 't'                                         
 	                                                           AND format_type(a.atttypid, a.atttypmod) NOT LIKE 'information_schema%' 
 	                                                       ) as pri,                                                                   
 	                                                       character_maximum_length as length                                           
 	                                                     FROM information_schema.COLUMNS                                               
 	                                                     WHERE table_name = 'matable'                                   
 	                                                     ORDER BY ordinal_position"  


 Comments   
Comment by Nahuel Alejandro Ramos [ 09/Nov/10 ]

We apply the diff patch you submit and works perfect. We are using Doctrine 1.2.3 with PostgreSQL 8.4.
We could generates models from database with generateModelsFromDb() method.
Please add this patch to a new release.
Thank you very much.

Comment by Tim Hemming [ 23/Nov/10 ]

We have applied this patch directly to our server-wide Doctrine library and it works fine. We look forward to it becoming a part of the Doctrine distribution.

Comment by Christopher Hotchkiss [ 19/Dec/10 ]

I can confirm that this bug also affects symfony 1.4.8 and the attached fix works perfectly!

Comment by David Landgren [ 21/Feb/11 ]

Confirmed to fix crash with symfony 1.3.8

Comment by Cesar Miggiolaro [ 09/Apr/12 ]

I use the version 1.4.17 and also had the error with postgres 9.1. Applying the correction suggested in DIFF. The system worked.





[DC-917] Doctrine take wrong connction Created: 05/Nov/10  Updated: 05/Nov/10

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

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


 Description   

I have problems with different connection
i am using doctrine with symfony, and i work with 2 connections
in base class i have bind to my connection

Doctrine_Manager::getInstance()->bindComponent('Datasource', 'doctrine');

symfony generate me

$this->datasources = Doctrine_Core::getTable('datasource')
->createQuery('a')
->execute();

and when i execute it show me error error that can find this table but it take wrong connection

by test i tried to add bind component as datasource (first is lower character and it works pretty cool)

then i change getTable('datasource') => getTable('Datasource') but it doesn't work
then i have added
test function to my datasource table

public static function test()

{ return Doctrine_Query::create()->from("Datasource")->execute(); }

and it works.






[DC-916] fetchOne defect Created: 05/Nov/10  Updated: 24/Jan/11

Status: Open
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Roman Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Query fetchOne method now retrieves and hydrates all collection, which can be time consumable. I suggest to add limit 1 in fetchOne method.



 Comments   
Comment by Gennady Feldman [ 21/Jan/11 ]

This is a defect. People assume there's an implied limit(1) in the query because of fetchOne(). Please fix this, this is pretty serious stuff.

Comment by Gennady Feldman [ 21/Jan/11 ]

Doctrine_Table actually "works around" the issue but explicitly doing limit(1) before doing fetchOne():

public function findOneBy($fieldName, $value, $hydrationMode = null)

{ return $this->createQuery('dctrn_find') ->where($this->buildFindByWhere($fieldName), (array) $value) ->limit(1) ->fetchOne(array(), $hydrationMode); }
Comment by Jonathan H. Wage [ 23/Jan/11 ]

Was this always like this or did it change recently?

Comment by Gennady Feldman [ 24/Jan/11 ]

Frankly I have no idea.

Also adding a limit(1) shouldn't break anything and is straight forward. We would also want to fix findOneBy not to do limit(1) since fetchOne() should take care of this after the fix is in place.





[DC-914] Doctrine_Pager ignores custom COUNT query Created: 02/Nov/10  Updated: 07/Nov/11

Status: Open
Project: Doctrine 1
Component/s: Pager
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Arnoldas Lukasevicius Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Zend Server CE



 Description   

I found some problem when I tried to define custom query for results counting. Defined custom COUNT query is totally ignored and executed default one. I will give you full description of problem bellow.

We have following source code:

 
$q_select = Doctrine_Query::create ()
->select ( 'DISTINCT p.product_name AS product_name' )
->from ( 'Product p' )
->where( 'p.product_name LIKE ?', '%motorola%');
				
$q_count = Doctrine_Query::create ()
->select ( 'COUNT (DISTINCT p.product_name) num_results' )
->from ( 'Product p' )
->where( 'p.product_name LIKE ?', '%motorola%');
												
$pager = new Doctrine_Pager( $q_select, 1, 25 );										
$pager->setCountQuery($q_count);

Let's check custom query before calling $pager->execute() method:

 
echo $pager->getCountQuery(); 

Output:

 
SELECT COUNT (DISTINCT p.product_name) num_results FROM Product p WHERE p.product_name LIKE ?

Looks like until now is everything is correct. Let's call $pager->execute() method:

 
$products = $pager->execute(); 

Let's check executed queries using Symfony SQL queries log panel:

SELECT COUNT(*) AS num_results FROM product p WHERE p.product_name LIKE '%motorola%'
7.27s, "doctrine" connection

SELECT DISTINCT p.product_name AS p__0 FROM product p WHERE (p.product_name LIKE '%motorola%') LIMIT 25
3.25s, "doctrine" connection

Executed COUNT query is not same we set using $pager->setCountQuery($q_count). Our defined custom COUNT query is totally ignored and executed default one:

INSTEAD OF THIS CUSTOM COUNT QUERY:

SELECT COUNT (DISTINCT p.product_name) num_results FROM Product p WHERE p.product_name LIKE '%motorola%'

EXECUTED DEFAULT COUNT QUERY:

SELECT COUNT(*) AS num_results FROM product p WHERE p.product_name LIKE '%motorola%'


 Comments   
Comment by Alex Cardoso [ 07/Nov/11 ]

I found a possible solution to the problem.

That occurs not because the Pager countQuery but in a method used inside the Query class.

When you set the Query or CountQuery for Pager and execute it, it calls a Query method called count(). This method by yourself call another Query class method named Query::getCountSqlQuery().

This method rather than simply execute the query that you passed earlier, simply create a new query.

Below is a possible solution to the problem:

Query.php (Doctrine Stable 1.2.4)


--- Query.php	2011-11-07 20:52:48.000000000 -0200
+++ Query.php	2011-11-07 20:51:58.000000000 -0200
@@ -2049,40 +2049,7 @@
         if (count($this->_queryComponents) == 1 && empty($having)) {
             $q .= $from . $where . $groupby . $having;
         } else {
-
-            // Subselect fields will contain only the pk of root entity
-            $ta = $this->_conn->quoteIdentifier($tableAlias);
-
-            $map = $this->getRootDeclaration();
-            $idColumnNames = $map['table']->getIdentifierColumnNames();
-
-            $pkFields = $ta . '.' . implode(', ' . $ta . '.', $this->_conn->quoteMultipleIdentifier($idColumnNames));
-
-            // We need to do some magic in select fields if the query contain anything in having clause
-            $selectFields = $pkFields;
-
-            if ( ! empty($having)) {
-                // For each field defined in select clause
-                foreach ($this->_sqlParts['select'] as $field) {
-                    // We only include aggregate expressions to count query
-                    // This is needed because HAVING clause will use field aliases
-                    if (strpos($field, '(') !== false) {
-                        $selectFields .= ', ' . $field;
-                    }
-                }
-                // Add having fields that got stripped out of select
-                preg_match_all('/`[a-z0-9_]+`\.`[a-z0-9_]+`/i', $having, $matches, PREG_PATTERN_ORDER);
-                if (count($matches[0]) > 0) {
-                    $selectFields .= ', ' . implode(', ', array_unique($matches[0]));
-                }
-            }
-
-            // If we do not have a custom group by, apply the default one
-            if (empty($groupby)) {
-                $groupby = ' GROUP BY ' . $pkFields;
-            }
-
-            $q .= '(SELECT ' . $selectFields . ' FROM ' . $from . $where . $groupby . $having . ') '
+            $q .= '( '.$this->getSqlQuery().' ) '
                 . $this->_conn->quoteIdentifier('dctrn_count_query');
         }
         return $q;




[DC-912] A method that can run in a model when the model is autoloaded Created: 01/Nov/10  Updated: 09/Nov/10

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

Type: New Feature Priority: Major
Reporter: will ferrer Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

XP Xamp


Attachments: Text File DC_912_fix.patch    

 Description   

For my project I needed to be able to reassign connections to models when they are autoloaded – this had to be able to happen during a conservative model loading process before the models had been instantiated. My solution was to build in a hook to a "autoloadSetUp" method which can be attached to any model (or class that is the base for a model).

I will post my patch after I make a test case for it.

Will Ferrer



 Comments   
Comment by will ferrer [ 02/Nov/10 ]

made test case use a static method

Comment by will ferrer [ 09/Nov/10 ]

fixed some compatibility issues with the test case and other test cases





[DC-911] A way of checking if a model has been loaded via the loaded loadModels method Created: 01/Nov/10  Updated: 02/Nov/10

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

Type: New Feature Priority: Major
Reporter: will ferrer Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

XP Xamp


Attachments: Text File DC_911_fix.patch    

 Description   

I needed a way to check if a model has been loaded — checking to see if the model was included in the _loadedModelFiles property of core.

I put in a simple function that allows me to test for this.

I will post the patch after building a test case for this ticket.

Will Ferrer



 Comments   
Comment by will ferrer [ 02/Nov/10 ]

Changed the name of the method to modelLoaded (seemed more appropriate)





[DC-910] Sub queries do not work properly in the on clause of a join Created: 01/Nov/10  Updated: 02/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: will ferrer Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

XP Xamp


Attachments: Text File DC_910_fix.patch    

 Description   

When subqueries are used in the on part of a join clause the Doctrine_Query_JoinCondition class does not always create the proper sql. For instance when there are 2 subqueries used in a between doctrine tries to parse the statement as 1 subquery rather 2 subqueries with an "and".

I will post my patch that fixes this issue after I make some test cases for it. I also fixed an issue where "(SQL:" syntax was breaking the join as well.

Will



 Comments   
Comment by will ferrer [ 02/Nov/10 ]

took out some commented code chunks





[DC-908] Can't save Doctrine Expression AES_ENCRYPT into a utf8_general_ci field Created: 31/Oct/10  Updated: 31/Oct/10

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

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

Win XP



 Description   

$membre = new Model_TMembre();
$membre->password = new Doctrine_Expression("AES_ENCRYPT(\"".htmlspecialchars($password,ENT_QUOTES)."\",\""._MYSQL_CRYPT."\")");
$membre->save();

Doesn't works id password field is encoded into utf8_general_ci .

Works fine id password field is encoded into latin1 .






[DC-907] when I delete fields from a table in oracle 10g and I execute build schema keeps bringing me those same fields that no longer exist. Created: 28/Jul/10  Updated: 31/Oct/10

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

Type: Bug Priority: Major
Reporter: fernando guerrero Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have a table in oracle that i was using but I had to change it so i remove some fields and add others when i run the task buils schema it generates the file schema.yml it created the new fields added but continued to bringing those field who had been eliminated and no longer existed in the database, it generates an error because the file schema.yml are those field but the database does not ...



 Comments   
Comment by Benjamin Eberlei [ 15/Sep/10 ]

Is this a Doctrine 1 or 2 bug? Is this a caching issue maybe?





[DC-904] Doctrine_Query (execute / fetchOne) memory leak Created: 29/Oct/10  Updated: 03/Dec/10

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

Type: Bug Priority: Major
Reporter: Marcin Dryka Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 3
Labels: None
Environment:

$ ./symfony -V
symfony version 1.4.8 (/home/marcin.dryka/htdocs/leak/lib/vendor/symfony/lib)

$ php -v
PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: Sep 17 2010 13:41:55)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

Ubuntu Server (lucid)



 Description   

I've created new symfony 1.4.8 project:

$ ./symfony -V
symfony version 1.4.8 (/home/marcin.dryka/htdocs/leak/lib/vendor/symfony/lib)

$ php -v
PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: Sep 17 2010 13:41:55)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

and set the database schema as follows:

$ cat config/doctrine/schema.yml
Example:
columns:
col1: string(255)
col2: string(255)
col3: string(255)
col4: string(255)
col5: string(255)
col6: string(255)

I created a task that contains a Doctrine_query call

(...)
protected function execute($arguments = array(), $options = array())
{
// initialize the database connection
$databaseManager = new sfDatabaseManager($this->configuration);
$connection = $databaseManager->getDatabase($options['connection'])->getConnection();

while(1)
{
$m = xdebug_memory_usage();
$q = Doctrine_Query::create()
->from('Example');
$o = $q->fetchOne();

if (false !== $o))

{ $o->free(true); }

unset($q, $o);

printf("Delta: %s Value: %s\n",
xdebug_memory_usage()-$m,
xdebug_memory_usage()
);
}
}
(...)

Unfortunately, memory usage is increasing:
./symfony leak
Delta: 3285264 Value: 10651596
Delta: 12944 Value: 10664448
Delta: 12952 Value: 10677308
Delta: 12932 Value: 10690148
Delta: 12932 Value: 10702988
Delta: 12932 Value: 10715828
Delta: 12932 Value: 10728668
Delta: 12932 Value: 10741508
Delta: 12932 Value: 10754348
Delta: 12932 Value: 10767188

Tested with and without data in database - result is the same.



 Comments   
Comment by sonic wang [ 03/Dec/10 ]

i found this bug too.

$rcs = $query->execute(array(),\Doctrine_Core::HYDRATE_ON_DEMAND);
$query->free();
//write to new table
foreach ($rcs as $rc)

{ $new = $table->create($rc->toArray()); $new->save(); $new->free(true); //free memory $rc->free(true); }

hydrate not cause memory leak

bug hydrate record will cause leak

so iterate Doctrine_collection will cause memory leak

Comment by Marcin Dryka [ 03/Dec/10 ]

Changing hydration doesn't work for me. Same result for:
HYDRATE_ON_DEMAND
HYDRATE_RECORD
HYDRATE_ARRAY





[DC-903] Make Doctrine_Record_UnknownPropertyException error more descriptive Created: 28/Oct/10  Updated: 28/Oct/10

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

Type: New Feature Priority: Major
Reporter: Jason Swett Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 10.10



 Description   

If I have a Doctrine object and I try something like $book->getNonexistantThing(), I always get an error like this:
PHP Fatal error: Class 'Doctrine_Record_UnknownPropertyException' not found in /home/jason/projects/mcif/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Record/Filter/Standard.php on line 55

It makes it hard to track down the source of the error. Why not have the error include the offending method call?






[DC-902] Xcache Cache Driver is not documented Created: 26/Oct/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Caching
Affects Version/s: 1.2.0-ALPHA1, 1.2.0-ALPHA2, 1.2.0-ALPHA3, 1.2.0-BETA1, 1.2.0-BETA2, 1.2.0-BETA3, 1.2.0-RC1, 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Piotr Leszczyński Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

All



 Description   

Xcache Cache Driver is not documented at all. Is it working? Is it stable? Can we use it?






[DC-899] Expose hardDelete method on node object when SoftDelete behavior is used Created: 22/Oct/10  Updated: 22/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Behaviors, Nested Set
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Fernando Varesi Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL



 Description   

When combining SoftDelete and NestedSet behavior, there's no way of calling hardDelete method on node object. According to documentation, to peform a delete on a nested set, delete should be called in node object, which will call delete method on the object itself.






[DC-898] (PATCH) Migration fails when addColumn with type 'boolean' used with default value, resulting in incorrect 'ALTER TABLE' query in MySQL Created: 22/Oct/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jakub Argasiński Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mac OS X 10.6 Snow Leopard / Zend Server CE 5.0.3 (irrelevant)


Attachments: Text File fix_boolean_default_mysql_column_migration.patch    

 Description   

I use MySQL. In my up() method in migration class, I have:

$this->addColumn($table, 'is_master', 'boolean', null, array('notnull' => true, 'default' => false));

Running 'migrate' results in a following exception:
Error #1 - SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for 'is_master'. Failing Query: "ALTER TABLE books_authors ADD is_master TINYINT(1) DEFAULT '' NOT NULL"
#0 /usr/local/zend/share/pear/Doctrine/Connection.php(1025): Doctrine_Connection->rethrowException(Object(PDOException), Object(Doctrine_Connection_Mysql), 'ALTER TABLE boo...')
#1 /usr/local/zend/share/pear/Doctrine/Export.php(621): Doctrine_Connection->execute('ALTER TABLE boo...')
#2 /usr/local/zend/share/pear/Doctrine/Migration/Process.php(89): Doctrine_Export->alterTable('books_authors', Array)
#3 /usr/local/zend/share/pear/Doctrine/Migration.php(522): Doctrine_Migration_Process->processCreatedColumn(Array)
#4 /usr/local/zend/share/pear/Doctrine/Migration.php(479): Doctrine_Migration->_doMigrateStep('up', 1)
#5 /usr/local/zend/share/pear/Doctrine/Migration.php(328): Doctrine_Migration->_doMigrate(1)
#6 /usr/local/zend/share/pear/Doctrine/Core.php(1016): Doctrine_Migration->migrate(NULL)
#7 /usr/local/zend/share/pear/Doctrine/Task/Migrate.php(41): Doctrine_Core::migrate('/Users/argasek/...', NULL)
#8 /usr/local/zend/share/pear/Doctrine/Cli.php(516): Doctrine_Task_Migrate->execute()
#9 /usr/local/zend/share/pear/Doctrine/Cli.php(498): Doctrine_Cli->executeTask(Object(Doctrine_Task_Migrate), Array)
#10 /usr/local/zend/share/pear/Doctrine/Cli.php(452): Doctrine_Cli->_run(Array)
#11 /Users/argasek/Sites/blipoteka/scripts/doctrine-cli.php(28): Doctrine_Cli->run(Array)
#12

{main}

However, I would expect ALTER query to look like this:

ALTER TABLE books_authors ADD is_master TINYINT(1) DEFAULT 0 NOT NULL

I guess there's a problem with getDefaultFieldDeclaration() in Doctrine_Export_Mysql, it lacks convertBooleans() call being present at Doctrine_Export.






[DC-897] Pager ignores default model hasMany ORDER BY statements, caused by getLimitSubquery ignoring same Created: 22/Oct/10  Updated: 10/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Pager
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Andrew Eross Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File Doctrine_Query.php.ORDERBY.patch    

 Description   

Our model configuration includes several hasMany statements, for example:

$this->hasMany('Subcategory as Subcategories', array(
'refClass' => 'SubcategoryTone',
'local' => 'tone_id',
'foreign' => 'subcategory_id',
'cascade' => array('delete'),
'orderBy' => 'order_id',
));

We noticed that the ORDER BY directive worked just fine with a normal query, but the order by was being ignored when we fed it into the Pager.

For example:
$aa = $t->execute(array(), Doctrine_Core::HYDRATE_ARRAY);
var_dump($aa[4]);

$pager = new Doctrine_Pager($t, $currentPage, $resultsPerPage);
$bb = $pager->execute(array(), Doctrine_Core::HYDRATE_ARRAY);

var_dump($bb[4]);

These two var_dumps would give different results because the ORDER BY is ignored by the limit subquery in the pager.



 Comments   
Comment by Andrew Eross [ 22/Oct/10 ]

I've also found a fix for the issue (thanks to George over here for finding the location of the problem) ... we found that simply moving the ORDER BY generation code inside of buildSqlQuery() to be ABOVE the if block containing getLimitSubquery() resolves the issue.

We're not super familiar with the Doctrine code-base, so everything looks to work fine after moving the code block, and it fixes the issue, but would love to hear if this is a real fix.

diff from 1.2.3 via our SVN:

Index: Query.php
===================================================================
— Query.php (revision 1120)
+++ Query.php (working copy)
@@ -1256,7 +1256,46 @@
$this->_sqlParts['where'][] = '(' . $string . ')';
}
}
+
+ // Fix the orderbys so we only have one orderby per value
+ foreach ($this->_sqlParts['orderby'] as $k => $orderBy) {
+ $e = explode(', ', $orderBy);
+ unset($this->_sqlParts['orderby'][$k]);
+ foreach ($e as $v)

{ + $this->_sqlParts['orderby'][] = $v; + }

+ }

+ // Add the default orderBy statements defined in the relationships and table classes
+ // Only do this for SELECT queries
+ if ($this->_type === self::SELECT) {
+ foreach ($this->_queryComponents as $alias => $map) {
+ $sqlAlias = $this->getSqlTableAlias($alias);
+ if (isset($map['relation'])) {
+ $orderBy = $map['relation']->getOrderByStatement($sqlAlias, true);
+ if ($orderBy == $map['relation']['orderBy']) {
+ if (isset($map['ref']))

{ + $orderBy = $map['relation']['refTable']->processOrderBy($sqlAlias, $map['relation']['orderBy'], true); + }

else

{ + $orderBy = null; + }

+ }
+ } else

{ + $orderBy = $map['table']->getOrderByStatement($sqlAlias, true); + }

+
+ if ($orderBy) {
+ $e = explode(',', $orderBy);
+ $e = array_map('trim', $e);
+ foreach ($e as $v) {
+ if ( ! in_array($v, $this->_sqlParts['orderby']))

{ + $this->_sqlParts['orderby'][] = $v; + }

+ }
+ }
+ }
+ }
+
$modifyLimit = true;
$limitSubquerySql = '';

@@ -1307,47 +1346,8 @@

$q .= ' WHERE ' . $limitSubquerySql . $where;
// . (($limitSubquerySql == '' && count($this->_sqlParts['where']) == 1) ? substr($where, 1, -1) : $where);

  • }
    + }
  • // Fix the orderbys so we only have one orderby per value
  • foreach ($this->_sqlParts['orderby'] as $k => $orderBy) {
  • $e = explode(', ', $orderBy);
  • unset($this->_sqlParts['orderby'][$k]);
  • foreach ($e as $v) { - $this->_sqlParts['orderby'][] = $v; - }
  • }
    -
  • // Add the default orderBy statements defined in the relationships and table classes
  • // Only do this for SELECT queries
  • if ($this->_type === self::SELECT) {
  • foreach ($this->_queryComponents as $alias => $map) {
  • $sqlAlias = $this->getSqlTableAlias($alias);
  • if (isset($map['relation'])) {
  • $orderBy = $map['relation']->getOrderByStatement($sqlAlias, true);
  • if ($orderBy == $map['relation']['orderBy']) {
  • if (isset($map['ref'])) { - $orderBy = $map['relation']['refTable']->processOrderBy($sqlAlias, $map['relation']['orderBy'], true); - }

    else

    { - $orderBy = null; - }
  • }
  • } else { - $orderBy = $map['table']->getOrderByStatement($sqlAlias, true); - }

    -

  • if ($orderBy) {
  • $e = explode(',', $orderBy);
  • $e = array_map('trim', $e);
  • foreach ($e as $v) {
  • if ( ! in_array($v, $this->_sqlParts['orderby'])) { - $this->_sqlParts['orderby'][] = $v; - }
  • }
  • }
  • }
  • }
    -
    $q .= ( ! empty($this->_sqlParts['groupby'])) ? ' GROUP BY ' . implode(', ', $this->_sqlParts['groupby']) : '';
    $q .= ( ! empty($this->_sqlParts['having'])) ? ' HAVING ' . implode(' AND ', $this->_sqlParts['having']): '';
    $q .= ( ! empty($this->_sqlParts['orderby'])) ? ' ORDER BY ' . implode(', ', $this->_sqlParts['orderby']) : '';
    @@ -1396,7 +1396,7 @@
    $subquery = 'SELECT DISTINCT ';
    }
    $subquery .= $this->_conn->quoteIdentifier($primaryKey);
    -
    +
    // pgsql & oracle need the order by fields to be preserved in select clause
    if ($driverName == 'pgsql' || $driverName == 'oracle' || $driverName == 'oci' || $driverName == 'mssql' || $driverName == 'odbc') {
    foreach ($this->_sqlParts['orderby'] as $part)
    Unknown macro: {@@ -1420,7 +1420,7 @@ // don't add primarykey column (its already in the select clause) if ($part !== $primaryKey) { $subquery .= ', ' . $partOriginal; - }+ }


    }
    }
    }

Property changes on: Query.php
___________________________________________________________________
Deleted: svn:keywords

  • Id Revision
    Deleted: svn:eol-style
  • LF
Comment by Andrew Eross [ 22/Oct/10 ]

Diff file

Comment by Andrew Eross [ 10/Nov/10 ]

patch -p0 ./libs/doctrine/Doctrine/Query.php ./Doctrine_Query.php.ORDERBY.patch





[DC-893] Using default value for bigint fields generates an error Created: 19/Oct/10  Updated: 25/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.3
Fix Version/s: None

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

Replicated on *nix using MySQL DB.



 Description   

A field defined as:
'user_id' => array(
   'type' => 'bigint',
   'length' => 22,
   'default' => 0,
),

Generates an error when create-tables is used:
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' [...] user_id bigint(22) DEFAULT , INDEX schedule_prize_id_idx (schedule_prize_id)[..]

The default value is not accounted for.



 Comments   
Comment by Paulo Vitor Reis [ 25/Oct/10 ]

20 is the length of the mysql bigint..





[DC-892] Typo. in Import/Pgsql.php Created: 19/Oct/10  Updated: 31/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nicolas Ippolito Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Linux and symfony1.4.9



 Description   

Hi,

There is maybe a typo. l. 194 in Doctrine/Import/Pgsql.php : typtype should be type?

Thanks



 Comments   
Comment by Piotr Leszczyński [ 31/Mar/11 ]

Happens to me as well, on windows.





[DC-889] Using RANDOM() AS rand as last field WITHOUT a comma between them works, but not randomly Created: 14/Oct/10  Updated: 14/Oct/10

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

Type: Bug Priority: Major
Reporter: Dennis Gearon Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ubuntu 64 bit, using a task in symfony



 Description   

The difference between the two code samples below is that there is a comma after 'lo.postal'_code in the second example:

This code DOES NOT RANDOMIZE But also DOES NOT PRODUCE A PARSER ERROR
$q = Doctrine_Query::create()
->select("li.id,
ap.name,
act.title, act.title_short, act.family_friendly,
o.unix_ts_begin, o.unix_ts_end,
act.description,
act.cost_min, act.tags, act.cost_min, act.cost_notes, act.organization,
lo.thoroughfare, lo.address_extra, lo.locality, lo.administrative_area, lo.country_name_code, lo.postal_code
RANDOM() AS rand")
->from(blah, blah)
->where(primary key equality statements for joining)
->orderBy('rand');

This DOES
$q = Doctrine_Query::create()
->select("li.id,
ap.name,
act.title, act.title_short, act.family_friendly,
o.unix_ts_begin, o.unix_ts_end,
act.description,
act.cost_min, act.tags, act.cost_min, act.cost_notes, act.organization,
lo.thoroughfare, lo.address_extra, lo.locality, lo.administrative_area, lo.country_name_code, lo.postal_code,
RANDOM() AS rand")
->from(blah, blah)
->where(primary key equality statements for joining)
->orderBy('rand');






[DC-888] Foreign key id columns do not respect ATTR_DEFAULT_IDENTIFIER_OPTIONS Created: 13/Oct/10  Updated: 13/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Migrations, Relations, Schema Files
Affects Version/s: 1.2.3
Fix Version/s: None

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

Any



 Description   

Some time ago Jon Wage suggested that one can override the 8-byte default integer type for IDs by setting Doctrine_Core::ATTR_DEFAULT_IDENTIFIER_OPTIONS in configureDoctrine (in a Symfony project), like this:

public function configureDoctrine(Doctrine_Manager $manager)

{ // Use 4-byte IDs for backwards compatibility with databases built on // Apostrophe 1.4, sfDoctrineGuard pre-5.0, etc. You don't need this for // a brand new site $options = $manager->getAttribute(Doctrine_Core::ATTR_DEFAULT_IDENTIFIER_OPTIONS); $options['length'] = 4; $manager->setAttribute(Doctrine_Core::ATTR_DEFAULT_IDENTIFIER_OPTIONS, $options); }

This works for primary key id columns. However it is not respected by foreign key id columns, which do not consult ATTR_DEFAULT_IDENTIFIER_OPTIONS.

I looked at working around this using ATTR_DEFAULT_COLUMN_OPTIONS, however it is not type-specific. So if you set a length of 4 with that option, it applies not just to all integers but also to dates, datetimes, booleans and many other things that definitely should not be 4 bytes.

The correct fix seems to be for foreign key id columns to respect ATTR_DEFAULT_IDENTIFIER_OPTIONS.

Also, ATTR_DEFAULT_COLUMN_OPTIONS should probably let you specify different defaults for each column type as the length option is basically not usable in its current form. But that would not be a particularly clean solution to the foreign key id problem since limiting non-ID integers to 4 bytes should not be necessary.

  • * *

The motivation for this bug report:

The new stable release of sfDoctrineGuardPlugin (for Symfony) does not specify an integer size as it formerly did, so the size of integers now defaults to 8 bytes. This breaks backwards compatibility with existing code that adds foreign key relationships to sfGuard objects like sfGuardUser, etc. Creating migrations to deal with changing this across all tables involved is quite difficult (all foreign key indexes must be dropped and recreated - doctrine:migrations-diff is unable to figure it out, understandably).






[DC-887] disabling deep option with toArray() drops relations in result Created: 13/Oct/10  Updated: 17/Apr/14

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

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

Attachments: Text File doctrine_toarray-deep_fix.patch    

 Description   

Using the toArray() on a Doctrine_Record object with the deep option set to true (default) correctly converts the whole object to an array including the relations.
But when the deep option is disabled the relations are not converted to array's (as expected) but they are lost, I would expect them to still be there in their original form (objects).

I've attached a fix. Another solution would be to add a flag that disables deep array conversion but enables relation persistence.






[DC-886] Doctrine should support mysql native float/double Created: 13/Oct/10  Updated: 13/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Schema Files
Affects Version/s: 1.2.3
Fix Version/s: None

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

symfony 1.4.8 / mysql



 Description   

Doctrine does not support native mysql float/double. It always specifies float(18,2) which reduces precission to 2 decimals.
Although it is possible via
type: float(18), scale: 6
to enhance precission, I experience the side-effect, that for example 76.86 is now stored as 76.860001
This ugly formatted number shows up in every form, unless I make an effort to round every field accordingly.

I think doctrine should support mysql native float/double!






[DC-885] Building schema doesn't work when tables have cross database foreign keys (MySQL). Created: 12/Oct/10  Updated: 12/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Schema Files
Affects Version/s: 1.2.3
Fix Version/s: None

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

Windows XP SP3, Apache 2, PHP 5.3, MySQL 5.1.36, Symfony 1.4.8.



 Description   

When building schema using the doctrine:build-schena task from multiple databases used in our project, the import process end up with a "missing classname" error without building the schema.yml file.

This seems to be caused by the fact that the tables contained in the databases contain foreign keys referencing the other databases tables pks.

As an example we have :

  • A main database (call it portal) that contains user's informations, and many other things.
  • a second database that contains business informations with some tables refererecing users informations contained in the main database.

When generating the schema, and specifically on the second database step, there are no informations found for the primary keys contained main database.

Digging in the import process, it seems that the issue comes from the fact that the Doctrine_Import.importSchema function creates a new definition array instance for every database encountered in the databases.yml.

The correction found for this was to take the array() creation one level up before the connections traversing.

original code :
public function importSchema($directory, array $connections = array(), array $options = array())
{
$classes = array();

$manager = Doctrine_Manager::getInstance();
foreach ($manager as $name => $connection) {
// Limit the databases to the ones specified by $connections.
// Check only happens if array is not empty
if ( ! empty($connections) && ! in_array($name, $connections))

{ continue; }

$builder = new Doctrine_Import_Builder();
$builder->setTargetPath($directory);
$builder->setOptions($options);

$definitions = array(); // <<<<<<<<<<<<<<<<<<< STAYING THERE CAUSES THE "MISSING CLASSNAME" ERROR

foreach ($connection->import->listTables() as $table) {
......

modified code :

public function importSchema($directory, array $connections = array(), array $options = array())
{
$classes = array();

$manager = Doctrine_Manager::getInstance();
$definitions = array(); // <<<<<<<<<<<<<<<<<<PUT HERE

foreach ($manager as $name => $connection) {
// Limit the databases to the ones specified by $connections.
// Check only happens if array is not empty
if ( ! empty($connections) && ! in_array($name, $connections)) { continue; }

$builder = new Doctrine_Import_Builder();
$builder->setTargetPath($directory);
$builder->setOptions($options);

foreach ($connection->import->listTables() as $table) {
.......






[DC-884] Doctrine_Collection::loadRelated uses getLocal instead of getLocalFieldName Created: 11/Oct/10  Updated: 18/Feb/13

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

Type: Bug Priority: Major
Reporter: Jason Brumwell Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 2
Labels: None
Environment:

Windows



 Description   

Having a camelcase fieldname with a lowercase column name causes loadRelated of doctrine collection to throw an unknown property error, fix:

Change

$rel     = $this->_table->getRelation($name);

        if ($rel instanceof Doctrine_Relation_LocalKey || $rel instanceof Doctrine_Relation_ForeignKey) {
            foreach ($this->data as $record) {
                $list[] = $record[$rel->getLocal()];
            }
        }

to:

$rel     = $this->_table->getRelation($name);

        if ($rel instanceof Doctrine_Relation_LocalKey || $rel instanceof Doctrine_Relation_ForeignKey) {
            foreach ($this->data as $record) {
                $list[] = $record[$rel->getLocalFieldName()];
            }
        }
public function populateRelated($name, Doctrine_Collection $coll)
    {
        $rel     = $this->_table->getRelation($name);
        $table   = $rel->getTable();
        $foreign = $rel->getForeign();
        $local   = $rel->getLocal();

to

public function populateRelated($name, Doctrine_Collection $coll)
    {
        $rel     = $this->_table->getRelation($name);
        $table   = $rel->getTable();
        $foreign = $rel->getForeignFieldName();
        $local   = $rel->getLocalFieldName();


 Comments   
Comment by Sebastian [ 12/Oct/11 ]

Now this is really poor. This trivial bug is known for over a year not but not yet fixed.

Fixing it would save millions of rainforrest trees because people would not have to rely on hundreds of lazy loading queries per page but start to use the getRelation() method.

Comment by Sebastian [ 18/Oct/12 ]

Two years now. :'-(

Comment by Mishal [ 18/Feb/13 ]

Another year, and all people are probably on Doctrine2.

But.... I just pushed your fix #DC-884 to my Doctrine1 fork, if you are interested.

https://github.com/mishal/doctrine1





[DC-882] Doctrine Collection FromArray doesn't adhere to KeyColumn Created: 09/Oct/10  Updated: 09/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.3
Fix Version/s: None

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


 Description   

Using the following in the base class:

$this->setAttribute(Doctrine_Core::ATTR_COLL_KEY, 'class');

Then executing a query to array the indexes of the entity are not that of the class field:

example:

array(
 0 => ..
 1 => ...
);

fix:

/**
     * Populate a Doctrine_Collection from an array of data
     *
     * @param string $array 
     * @return void
     */
    public function fromArray($array, $deep = true)
    {
        $data = array();
        foreach ($array as $rowKey => $row) {
            $this[$rowKey]->fromArray($row, $deep);
        }
    }

to

/**
     * Populate a Doctrine_Collection from an array of data
     *
     * @param string $array 
     * @return void
     */
    public function fromArray($array, $deep = true)
    {
        $data = array();
        $keyColumn = $this->keyColumn;
        foreach ($array as $rowKey => $row) {
            $rowKey = $keyColumn AND isset($row[$keyColumn]) ? $row[$keyColumn] : $rowKey;
            $this[$rowKey]->fromArray($row, $deep);
        }
    }





[DC-881] Doctrine_Manager::parsePdoDsn() doesn't work properly [+patch] Created: 08/Oct/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Connection
Affects Version/s: 1.2.3
Fix Version/s: None

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


 Description   

Doctrine_Manager::parsePdoDsn('dblib:host=127.0.0.1:1433;dbname=foo') does not return proper results.

patch and test case @ github






[DC-880] Versionable + I18n creates additional migration with irrelevant data Created: 06/Oct/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Behaviors, I18n, Migrations, Relations
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

PHP 5.2, Symfony 1.4, Diem 5.1, Doctrine 1.2.2



 Description   

First run of generate-migrations-diff and migrate creates 2 migration diff files. First one for new tables, second one for new indexes and foreign keys. Than if I run generate-migrations-diff again another version is created although nothing was changed and following is inside:

  • 1st entry tries to drop a foreign key never been created and not existing in file
  • next entry tries to create a foreign key already existing
  • 3rd entry tries to create an existing index

After a long try and errorI found out that it's only happening with I18n plus Versionable behavior.

As I already have spent much time for a report please have also a look at: http://forum.diem-project.org/viewtopic.php?f=2&t=173&sid=5e0e3349c0e15a169bc9990a3104b3f6#p465

As I'm quite new to Doctrine and Symfony systems I cannot get further, but willing for more investigation if just one could give me a hint where to start.



 Comments   
Comment by Andrew Coulton [ 10/Oct/10 ]

I think this is because the versionable behaviour doesn't define a table name in the Doctrine_Template_Versionable class. As a result, if using model prefixes, the prefixes are not discarded from the table names when the behaviour model classes are built. This means that the tables have different names to what is expected, so they have different index keys, so the indexes are dropped and recreated as part of the migration.

I have committed unit tests and patch for this issue (which applies to Searchable also) to http://github.com/acoulton/doctrine1/tree/DC-880

Comment by Daniele Dore [ 19/Sep/11 ]

I experienced the same problem in the latest version 1.2.4, and the patch proposed by Andrew Coulton solves the problem.
Why the fix is not included in official release?





[DC-878] cannot access the version models using object->CLASSNAMEVersion in v1.2.3 Created: 30/Sep/10  Updated: 07/Oct/10

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

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

PHP Version 5.2.10-2ubuntu6.5 ; Suhosin Patch 0.9.7 ; Ubuntu 9.10 2.6.31-22-generic x86_64 ; Apache/2.2.12 (Ubuntu) PHP/5.2.10-2ubuntu6.5 with Suhosin-Patch ; Doctrine 1.2.3



 Description   

In Doctrine 1.1 if I said

$vAaaaa = Doctrine::getTable('Aaaaa')->find(1);
print_r( $vAaaaa->AaaaaVersion ); // print_r( $vAaaaa->AaaaaVersion[0]->toArray() );

then I got the corresponding version model/array. Our application is using this nice behaviour at several places. But then the project got upgraded to Doctrine 1.2.3, and since then it dies saying

Unknown record property / related component "UserVersion" on "User" on line 55 of file /home/roland/www/cabcall/library/Doctrine/Doctrine/Record/Filter/Standard.php
#0 /home/roland/www/cabcall/library/Doctrine/Doctrine/Record.php(1395): Doctrine_Record_Filter_Standard->filterGet(Object(User), 'UserVersion')
#1 /home/roland/www/cabcall/library/Doctrine/Doctrine/Record.php(1350): Doctrine_Record->_get('UserVersion', true)
#2 /home/roland/www/cabcall/library/Doctrine/Doctrine/Access.php(72): Doctrine_Record->get('UserVersion')
#3 /home/roland/www/cabcall/application/controllers/TestController.php(12): Doctrine_Access->__get('UserVersion')
#4 /home/roland/www/cabcall/library/Zend/Controller/Action.php(513): TestController->indexAction()
#5 /home/roland/www/cabcall/library/Zend/Controller/Dispatcher/Standard.php(295): Zend_Controller_Action->dispatch('indexAction')
#6 /home/roland/www/cabcall/library/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#7 /home/roland/www/cabcall/library/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#8 /home/roland/www/cabcall/library/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#9 /home/roland/www/cabcall/public/index.php(64): Zend_Application->run()
#10

{main}

Here is the exact example I tried before posting:

Aaaaa:
    tableName: aaaaa
    columns:
        something:
            type: integer(8)
            unsigned: false
            notnull: true
            default: 0
    actAs:
        Versionable:
            versionColumn: version
            className: %CLASS%Version
            auditLog: true
            deleteVersions: true


class AaaaaTable extends Doctrine_Table
{
    /**
     * Returns an instance of this class.
     *
     * @return object AaaaaTable
     */
    public static function getInstance()
    {
        return Doctrine_Core::getTable('Aaaaa');
    }
}


abstract class BaseAaaaa extends Doctrine_Record
{

    public function setTableDefinition()
    {
        $this->setTableName('aaaaa');
        $this->hasColumn('something', 'integer', 8, array(
             'type' => 'integer',
             'unsigned' => false,
             'notnull' => true,
             'default' => 0,
             'length' => '8',
             ));

        $this->option('type', 'INNODB');
        $this->option('collate', 'utf8_general_ci');
        $this->option('charset', 'utf8');
    }

    public function setUp()
    {
        parent::setUp();
        $versionable0 = new Doctrine_Template_Versionable(array(
             'versionColumn' => 'version',
             'className' => '%CLASS%Version',
             'auditLog' => true,
             'deleteVersions' => true
             ));

        $this->actAs($versionable0);
    }

}


class Aaaaa extends BaseAaaaa
{

}


/*
$vAaaaa = New Aaaaa;
$vAaaaa->something = 1;
$vAaaaa->save();
*/

$vAaaaa = Doctrine::getTable('Aaaaa')->find(1);

print_r( $vAaaaa->AaaaaVersion );



 Comments   
Comment by Roland Huszti [ 01/Oct/10 ]
<?php

class OSS_Resource_Doctrine extends Zend_Application_Resource_ResourceAbstract
{
    /**
     * Holds the Doctrine instance
     *
     * @var
     */
    protected $_doctrine;


    public function init()
    {
        // Return Doctrine so bootstrap will store it in the registry
        return $this->getDoctrine();
    }


    public function getDoctrine()
    {
        if ( null === $this->_doctrine )
        {
            // Get Doctrine configuration options from the application.ini file
            $doctrineConfig = $this->getOptions();

            require_once 'Doctrine.php';

            $loader = Zend_Loader_Autoloader::getInstance();
            $loader->pushAutoloader( array( 'Doctrine', 'autoload' ) );
            $loader->pushAutoloader( array( 'Doctrine', 'modelsAutoload' ) );

            $manager = Doctrine_Manager::getInstance();

            $manager->setAttribute( Doctrine::ATTR_MODEL_LOADING, Doctrine::MODEL_LOADING_CONSERVATIVE );
            $manager->setAttribute( Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES, true );
            $manager->setAttribute( Doctrine::ATTR_USE_DQL_CALLBACKS, true );

            $manager->setCollate( 'utf8_unicode_ci' );
            $manager->setCharset( 'utf8' );

            Doctrine::loadModels( $doctrineConfig['models_path'] );

            $db_profiler = new Doctrine_Connection_Profiler();

            $manager->openConnection( $doctrineConfig['connection_string'] );
            $manager->connection()->setListener( $db_profiler );

            $manager->connection()->setCollate('utf8_unicode_ci');
            $manager->connection()->setCharset('utf8');

            Zend_Registry::set( 'db_profiler', $db_profiler );

            $this->_doctrine = $manager;
        }

        return $this->_doctrine;
    }

    /**
     * Set the classes $_doctrine member
     *
     * @param $doctrine The object to set
     */
    public function setDoctrine( $doctrine )
    {
        $this->_doctrine = $doctrine;
    }

}

Comment by Roland Huszti [ 07/Oct/10 ]

To have this very nice and useful feature, I had to add these lines by hand to my audited table's models. Not to the base models, those are overwritten every time you migrate to a new version! Also, in the YAML file you can set the classname to whatever you want, so you need to use the same name in the model, too!

MODEL

class XYZ extends BaseXYZ

{


    public function setUp()

    {

        parent::setUp();

        $this->hasMany('XYZVersion', array( 'local' => 'id', 'foreign' => 'id'));

        // you may get the classname from the model, so then you only need to copy-paste the exact same piece of setUp() code into every model you want to
    }


    . . .

YAML

    actAs:
        Versionable:
            versionColumn: version
            className: %CLASS%Version    # this is the default, User -> UserVersion , Address -> AddressVersion, etc.
            auditLog: true
            deleteVersions: true




[DC-877] Hydrator fatal error: Found non-unique key mapping named 'lang' Created: 30/Sep/10  Updated: 22/Oct/10

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

Type: Bug Priority: Major
Reporter: Ilya Sabelnikov Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.2.13


Attachments: File Ticket_DC877_TestCase.php    

 Description   

You could find the ticket's test case in the attachments.






[DC-876] Basic Request return one element. Created: 30/Sep/10  Updated: 05/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rudybruneau Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Windows XP Pro. Service Pack 3, Eclipe PDT, Doctrine 1.2.3, Php 5.2.11


Attachments: JPEG File image.jpg    

 Description   

i try to get all preferences with an IdUser specified.

schema.yml
UserHasPreference:
  connection: hopscore
  actAs:
    I18n:
      fields: [value]
    Timestampable:
      created:
        name: created_at
        type: timestamp
        format: Y-m-d H:i:s
  columns:
    idUserHasPreference:
      name: idUserHasPreference as id
      type: integer(4)
      unsigned: true
      primary: true
      autoincrement: true
    UsersIdUser:
      name: UsersIdUser as idUser
      type: integer(4)
      unsigned: true
      notnull: true
    PreferencesIdPreference:
      name: PreferencesIdPreference as idPreference
      type: integer(4)
      unsigned: true
      notnull: true
    MatchLinksMatchLinkId:
      name: MatchLinksMatchLinkId as MatchLinkId
      type: integer(4)
      unsigned: true
      notnull: true
    value:
      type: string(100)
  relations:
    Users:
      class: User
      local: idUser
      foreign: id
      type: one
    Preferences:
      class: Preference
      local: idPreference
      foreign: id
      type: one
    MatchLinks:
      class: MatchLink
      local: MatchLinkId
      foreign: id
      type: one
  options:
    collate: utf8_unicode_ci
    charset: utf8
Doctrine Request
$preferences = Doctrine_Query::create()
		->select('uhp.idPreference as idPref')
		->addSelect('uhpt.value as value')
		->addSelect('uhp.MatchLinkId as idItem')
		->from('UserHasPreference uhp')
		->innerJoin('uhp.Translation uhpt')
		->where('uhp.idUser = ?', intval($idUser))
		->execute(array(), Doctrine::HYDRATE_ARRAY);
	    return $preferences;

With $preferences->getSqlQuery(); and getParams(); and report this SQL query in phpmydadmin.
With SQL i have 13 elements. But in my object $preference i have one element (Doctrine::HYDRATE_ARRAY)
With "Doctrine::HYDRATE_NONE", i have 13 elements as SQL query.



 Comments   
Comment by Eirik Hoem [ 05/Oct/10 ]

I have the same problem, and I think this is related to the select statement. It seems that a select statement where all fields are aliased will cause this behavior. A simple work-around is to select one field without aliasing it.

Code for reproducing / work-around:

$query = Doctrine_Query::create();
$query->from('Results r');
$query->select('p.id as myid, r.value as foo');
$query->innerJoin('r.Profil p on (r.pid=123)');
$results = $query->execute(array(), Doctrine_Core::HYDRATE_ARRAY);

count($results) = 1

$query = Doctrine_Query::create();
$query->from('Results r');
$query->select('p.id as myid, r.value');
$query->innerJoin('r.Profil p on (r.pid=123)');
$results = $query->execute(array(), Doctrine_Core::HYDRATE_ARRAY);

count($results) = 250





[DC-875] One-to-many relationship returns Doctrine_Record instead of Doctrine_Collection Created: 30/Sep/10  Updated: 14/Sep/11

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

Type: Bug Priority: Major
Reporter: Patrik Åkerstrand Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

WAMP:
Windows 7 - 64bit
Apache 2.2
PHP 5.3.1
MySQL 5.1.41



 Description   

I've run into a bit of a snag in my application where a relationship defined as a one-to-many relationship returns a model object (instance of Doctrine_Record) instead of a Doctrine_Collection when I try to access it as $model->RelatedComponent[] = $child1. This, of course, yields an exception like so:

Doctrine_Exception: Add is not supported for AuditLogProperty
#0 path\library\Doctrine\Access.php(131): Doctrine_Access->add(Object(AuditLogProperty))
#1 path\application\models\Article.php(58): Doctrine_Access->offsetSet(NULL, Object(AuditLogProperty))
#2 path\library\Doctrine\Record.php(354): Article->postInsert(Object(Doctrine_Event))
#3 path\library\Doctrine\Connection\UnitOfWork.php(576): Doctrine_Record->invokeSaveHooks('post', 'insert', Object(Doctrine_Event))
#4 path\library\Doctrine\Connection\UnitOfWork.php(81): Doctrine_Connection_UnitOfWork->insert(Object(Article))
#5 path\library\Doctrine\Record.php(1718): Doctrine_Connection_UnitOfWork->saveGraph(Object(Article))
#6 path\application\modules\my-page\controllers\ArticleController.php(26): Doctrine_Record->save()
#7 path\library\Zend\Controller\Action.php(513): MyPage_ArticleController->createAction()
#8 path\library\Zend\Controller\Dispatcher\Standard.php(289): Zend_Controller_Action->dispatch('createAction')
#9 path\library\Zend\Controller\Front.php(946): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#10 path\library\Zend\Application\Bootstrap\Bootstrap.php(77): Zend_Controller_Front->dispatch()
#11 path\library\Zend\Application.php(358): Zend_Application_Bootstrap_Bootstrap->run()
#12 path\public\index.php(11): Zend_Application->run()
{{#13

{main}

}}

This is what my yaml-schema looks like (excerpt):

schema.yml
AuditLogEntry:
  tableName: audit_log_entries
  actAs:
    Timestampable:
      updated: {disabled: true}
  columns:
    user_id: {type: integer(8), unsigned: true, primary: true}
    id: {type: integer(8), unsigned: true, primary: true, autoincrement: true}
    type: {type: string(255), notnull: true}
    mode: {type: string(16)}
    article_id: {type: integer(8), unsigned: true}
    comment_id: {type: integer(8), unsigned: true}
    question_id: {type: integer(8), unsigned: true}
    answer_id: {type: integer(8), unsigned: true}
    message_id: {type: integer(8), unsigned: true}
  indexes:
#   Must index autoincrementing id-column since it's a compound primary key and 
#   the auto-incrementing column is not the first column and we use InnoDB.
    id: {fields: [id]}
    type: {fields: [type, mode]}
  relations:
    User:
      local: user_id
      foreign: user_id
      foreignAlias: AuditLogs
      type: one
      onDelete: CASCADE
      onUpdate: CASCADE
AuditLogProperty:
  tableName: audit_log_properties
  columns:
    auditlog_id: {type: integer(8), unsigned: true, primary: true}
    prop_id: {type: integer(2), unsigned: true, primary: true, default: 1}
    name: {type: string(255), notnull: true}
    value: {type: string(1024)}
  relations:
    AuditLogEntry:
      local: auditlog_id
      foreign: id
      type: one
      foreignType: many
      foreignAlias: Properties
      onDelete: CASCADE
      onUpdate: CASCADE

Now, if we look at the generated class-files, it looks fine:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
/**
 * @property integer $user_id
 * @property integer $id
 * @property string $type
 * @property string $mode
 * @property integer $article_id
 * @property integer $comment_id
 * @property integer $question_id
 * @property integer $answer_id
 * @property integer $message_id
 * @property integer $news_comment_id
 * @property User $User
 * @property Doctrine_Collection $Properties
 * @property Doctrine_Collection $Notifications
 */
abstract class BaseAuditLogEntry extends Doctrine_Record

/**
 * @property integer $auditlog_id
 * @property integer $prop_id
 * @property string $name
 * @property string $value
 * @property AuditLogEntry $AuditLogEntry
 */
abstract class BaseAuditLogProperty extends Doctrine_Record

However, when I later try to add properties I get the exception posted in the beginning of the question:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
$auditLog = new AuditLogEntry();
$prop1 = new AuditLogProperty();
$prop1->name = 'title';
$prop1->value = $this->Content->title;
$prop2 = new AuditLogProperty();
$prop2->name = 'length';
$prop2->value = count($this->Content->plainText);
$auditLog->Properties[] = $prop1;
$auditLog->Properties[] = $prop2;
$auditLog->save();

If I do the following:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
var_dump(get_class($auditLog->Properties));

I get that Properties is of type AuditLogProperty, instead of Doctrine_Collection.

I use version 1.2.3 of Doctrine.



 Comments   
Comment by Trevor Wencl [ 14/Sep/11 ]

I am having the same issue and it is killing my application. Using your example, when I call:

var_dump(get_class($auditLog->Properties));

... and there are no AuditLogProperty records, I would expect either an empty Doctrine_Collection or null, but instead I get a new instance of AuditLogProperty with null values for the properties.





[DC-874] Allow parameters to be passed to Doctrine_Query::select() Created: 30/Sep/10  Updated: 23/Dec/10

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

Type: Improvement Priority: Major
Reporter: Gerry Vandermaesen Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Any



 Description   

While I believe it's not so extraordinary to have parameters in a SELECT clause, Doctrine_Query::select() does not allow to pass parameters, next to the SELECT clause. You can still pass any parameters to execute(), but I do believe it would be nice to be able to pass the parameter values right away to select() as you can with where() etc.

Example:

Doctrine_Query::create()>select('f.*, (f.id = ?) AS selected'))>from('Foo f')->execute(array($selected_id));

This principle would apply to any select-field that has a calculated value that comes from a parameter.



 Comments   
Comment by Piotr Leszczyński [ 23/Dec/10 ]

I believe this should be major improvement for Doctrine. Without this feature, some queries can't be created.





[DC-873] Update Execute Params do not persist Created: 26/Sep/10  Updated: 26/Sep/10

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

Type: Bug Priority: Major
Reporter: Kyle Clarke Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

LAMP php5.2.6 Symfony 1.4



 Description   

I have been trying to update numerous records with the one doctrine_query object (which could be my problem) and passing the query execute params to persist to the dbase. eg

$q = Doctrine_Query::create()
->update('TdPackageType pt')
->set('pt.name', '?')
->set('pt.group_type_id', '?')
->where('pt.id = ?')
;

Then iterating over an array of values, passing the required values to the execute method eg
foreach($foobars as $foobar) {
$q->execute(array($foobar[0], $foobar[1], $foobar[2]));
}

I thought this the best way by creating only the one query instance and then assigning the vars as required. Trouble being, the data did not persist? I had no errors returned from Doctrine - eg I had the correct number of matched params - but the update would not update. To move on I ended up instantiating a new query object each time I iterated over my array of data values. eg

foreach($foobars as $foobar) {

$q = Doctrine_Query::create()
->update('TdPackageType pt')
->set('pt.name', '?', $foo[0])
->set('pt.group_type_id', '?', $foo[1])
->where('pt.id = ?', $foo[2])
;

$q->execute();
}

The values did then persist correctly to the dbase? Am I missing something really fundamental here? eg I would have thought the first code struct was a much better design to re-use the one query object. Or is it as silly as me not adding a hydration method to the execute method?

Any all help appreciated.
Thanks
Kyle






[DC-871] When importing fixtures some times the fixtures will be loaded in the wrong order causing broken foreign key relations Created: 20/Sep/10  Updated: 20/Sep/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

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

XP Xamp


Attachments: Text File DC_871_fix.patch    

 Description   

Hi

I recently encountered a problem when importing fixtures. I was ending up with invalid foreign key constraints due to the fact that the fixtures were importing in the wrong order. I tracked down the problem and figured out that the method Doctrine_Connection_UnitOfWork::buildFlushTree, while a truly impressive piece of sorting logic still some times still gets the order of the classes wrong in its end result.

I realized that all it needed though was a second shot at reordering the list – in other words it needed to exhaustively try to order the list until it found that everything was in the right order.

I put in a for loop in this method that will keep running until no order changes occurred or until a max number of attempts have been reached. The max number of attempts I added as a property of Doctrine_Connection called: maxBuildFlushTreeOrderAttempts.

This has solved my problem. I wouldn't be surprised if this was a common issue.

I will post my patch into this thread.

Hope all is well.

Will Ferrer



 Comments   
Comment by will ferrer [ 20/Sep/10 ]

Here is the patch





[DC-870] NestedSet not moving children of child nodes correctly Created: 20/Sep/10  Updated: 20/Sep/10

Status: Open
Project: Doctrine 1
Component/s: Nested Set
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ashley Broadley Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 10.04 x64
PHP 5.3.2



 Description   

The best way I can explain the issue is with code. Please see the below:

<?php

$root = new Test();
$root->name = '1';
$root->save();

// Create root node
$tree = Doctrine::getTable('Test')->getTree();
$tree->createRoot($root);

// Create child node
$child1 = new Test();
$child1->name = '2';
$child1->save();

// Add child
$child1->getNode()->moveAsLastChildOf($root);

// Create child node
$child2 = new Test();
$child2->name = '3';
$child2->save();

// Add child2 as node of child1
$child2->getNode()->moveAsLastChildOf($child1);

// Create child node
$child3 = new Test();
$child3->name = '4';
$child3->save();

// Add child3 as node of child2
$child3->getNode()->moveAsLastChildOf($child2);

// Add another root just to be nice
$root2 = new Test();
$root2->name = '5';
$root2->save();

// Create root node
$tree->createRoot($root2);

/**
 * Now we have the following tree (Each '-' indicates 1 level):
 * 1
 * - 2
 * - - 3
 * - - - 4
 * 5
 */

/**
 * Lets say I want to move node '3' to be a root.
 * With this I assume that all of the current nodes
 * children will be moved with it:
 */
$tree->createRoot(child2);

/**
 * Now the (implied) tree should look like this:
 * 1
 * - 2
 * 3
 * - 4
 * 5
 * 
 * Instead, the tree actually looks like this:
 * 1
 * - 2
 * - - - 4
 * 3
 * 5
 */

/**
 * I will now demostrate incorrect moving back of child nodes.
 */
$child2->getNode()->moveAsLastChildOf($child1);
/**
 * Now the tree should go back to looking like this:
 * 1
 * - 2
 * - - 3
 * - - - 4
 * 5
 * 
 * But the tree now looks like this:
 * 1
 * - 2
 * - - - 4
 * - - 3
 * 5
 */


 Comments   
Comment by Ashley Broadley [ 20/Sep/10 ]

Fixing code spacing

Comment by Ashley Broadley [ 20/Sep/10 ]

I have also noticed that moving a root node back into its original position as a child also corrupts the tree. I have added an example to the original post





[DC-869] calling getLastModified() after saving the object without any modifications returns the last modified fields Created: 17/Sep/10  Updated: 17/Sep/10

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

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

symfony-1.4.6



 Description   

_resetModified() function in Record.php fails to reset $this->_lastModified the second time the object is saved.






[DC-867] Doctrine::ATTR_IDXNAME_FORMAT and Doctrine::ATTR_FKNAME_FORMAT are inconsistently applied during migrations Created: 15/Sep/10  Updated: 07/Sep/11

Status: Open
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ryan Lepidi Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

postgres 8.4



 Description   

Given the following code:

    public function up()
    {
        $idx = array(
            'fields' => array('profile_id')
        );

        $this->addIndex('schedules', 'ix_schedules_profile_id', $idx);
    }
    public function down()
    {
        $this->removeIndex('schedules', 'ix_schedules_profile_id');
    }

The "up" function will try to create "ix_schedules_profile_id", but the "down" function will try to remove "ix_schedules_profile_id_idx". The same problem exists with foreign keys. The add/remove functions should both use the formatter, or neither should.



 Comments   
Comment by John Kary [ 07/Sep/11 ]

Appears to be duplicate of DC-830





[DC-866] Bug In Debian "Can't parse dsn.."! Created: 13/Sep/10  Updated: 15/Sep/10

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

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

Debian4 PHP 5.3.1



 Description   

config dsn: sqlite:///root/db3.db

i find parse_url will cause the problem

------------------
$dsn = str_replace("////", "/", $dsn);
$dsn = str_replace("
", "/", $dsn);
$dsn = preg_replace("/\/\/\/(.*):\//", "//$1:/", $dsn);

this fix will be correct in windows ,because dsn is sqlite://C:/aa/wafdb.db3

--------------------------------------------------------------

but in debian it will be fail.






[DC-865] Models that extend a baseclass other than Doctrine_Record treat that baseclass as if it were a model Created: 11/Sep/10  Updated: 11/Sep/10

Status: Open
Project: Doctrine 1
Component/s: Cli, Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

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

XP Windows


Attachments: Text File DC_865_fix.patch    

 Description   

We recently made an extended version of Docrtine_Record which has some functionality that is specific to our project and we switched all our models to use this baseclass by setting the cli option: generate_models_options:baseClassName

We found that when we rebuilt our db this base class was being treated as it were a model (even though its an abstract class). This was causing some errors during our build and a table based on the name of the baseclass was being created.

I tracked the problem down to line 310 of Doctrine_Table where the do loop was only breaking for a class named "Doctrine_Record".

It seemed to make more sense to me to have this loop break for any abstract class, so I copied the technique used to check for abstract classes from Doctrine_Core Line 798. This broke a lot of tests however so due to time constraints I went with a simpler fix – instead I just changed the code that checks if the class is named "Doctrine_Record" to be a regular expression that checks to see if the class name starts with "Doctrine_Record" optionally followed by an underscore + more text in the class name.

This has fixed my issue and should let people make extensions of doctrine record which they can use as a baseclass provided that their class names indicate that they are extending Doctrine_Record.

The only problem I can see arising from this if some users have made models that they have named starting with "Doctrine_Record", but that seems like it would be an odd thing to do so this probably it won't be an issue.

I could however look more closely into detecting abstract classes if this would make my changes significantly more useful.

Please see attached patch.

Will Ferrer



 Comments   
Comment by will ferrer [ 11/Sep/10 ]

Here is the patch





[DC-863] Connection.UnitOfWork::buildFlushTree when loading data from yml file, Incorrect ordering of tables by their relations Created: 10/Sep/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Connection, Data Fixtures
Affects Version/s: 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ochoo Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

symfony 1.4.6, windows 7, apache2.2, php5.3.3, mySQL 5.1.49-community


Attachments: File schema.yml     File test.yml    

 Description   

I don't know where exactly to start, I'm new here, and i'm not even sure this is a bug. BUT

We have a database structure with most important tables' PK's as string fields, which function as FK on other tables the basic structure is:

Artist
-Album
-Song
-Comments

each artist has multiple songs
each artist has multiple albums
each album has multiple songs that belong to the same artist as the album belongs to
each song has multiple comments

thus, the UnitOfWork - builtFlushTree should generate

[0]=>Artist
[1]=>Album
[2]=>Song
[3]=>Comments

but instead i get:
[0] => Album
[1] => Artist
[2] => Song
[3] => Lyrics

which in turn generates:

QLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`lyrics`.`album`, CONSTRAINT `album_artist_fk_stripped_name_artist_stripped_name` FOREIGN KEY (`artist_fk_stripped_name`) REFERENCES `artist` (`stripped_name`) ON DELETE CASCADE ON UPDATE CASC)
obviously.

I've been going through symfony/doctrine code for a whole day trying to figure out why I can't load-data. in the end i get to this buildFlushTree function.
probably have to go deeper. but so far this is it

PS. It's my decision to use string fields as PK's and FK even though it's a bad practice, but just because it is a bad practice I shouldn't be unable to work with it.



 Comments   
Comment by Ochoo [ 10/Sep/10 ]

found a tiny BUG, submitting the fix.

EDIT: scratch the rest from here.

<!-----------
still, fixing the bug does not resolve the issue
BECAUSE:
the whole logic of ordering the tables is flawed! it can be proved, don't have time to do so. but trying to come up with a fix myself

instead of looping through the tables and then through each tables' related tables, either have a recursive function OR implement user defined array sort function, latter of which seems like the proper and correct way to go
-->

Comment by Ochoo [ 10/Sep/10 ]

unfortunately i'm unable to commit any changes i have made. just me being a newbie, any help is appreciated

Comment by Ochoo [ 10/Sep/10 ]

on UnitOfWork.php of Doctrine ORM 1.2.3
Revision 7684
right after the line 752:
array_splice($flushList, $index, 0, $relatedClassName);
there should be:
$index++;

Comment by atali daoud [ 29/Nov/10 ]

@Ochoo: Even with your bugfix, it doesn't seem to work.

Comment by Ochoo [ 01/Dec/10 ]

thanks atali, i haven't checked it on 1.2.3, just did and you're right. the "bug fix" worked on 1.2.0 but not on 1.2.3. I'm gonna look into it, at least i'll try. but this is a bug right?





[DC-862] INNER JOIN example is same as previous LEFT JOIN example Created: 08/Sep/10  Updated: 08/Sep/10

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

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

http://www.doctrine-project.org/projects/orm/1.2/docs/manual/dql-doctrine-query-language/en#join-syntax



 Description   

I was reading the "JOIN syntax" section of the documentation. The docs first talk about how the default join type is LEFT JOIN and an example is presented. Next, INNER JOINS are discussed, but the example is the same left join example used previously. Am I misunderstanding the flow of the document?






[DC-859] Diff generator doesn't load models from specified paths Created: 06/Sep/10  Updated: 08/Sep/10

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

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

WinXP, PHP 5.3.3


Attachments: Zip Archive Doc1_migration_model_loading_bug.zip    

 Description   

Adding simple testcase, I have two version of PHP model, they differ in primary key.
version 0 has: stateid = Integer (classic id number)
version 1 has: stateid = char(2) (fixed length)

After I run Doctrine_Core::generateMigrationsFromDiff, doctrine will load only the integer model and compare it, so no difference is detected and no migration script created.

I'm attaching simple project where it doesn't work (adjust please LIBS_DIR definition for your setup).

From current codepath I would say when YAML is used, the from/to classes get prefixes.
When php model directories are used, the classes don't have have prefixes and their names are identical.
I think this may be one part of problem.

Trying to generate YAML files instead from php models lead to migration script dropping all tables. (looks like it's already reported as DC-755)
I did call both yaml generation and diff tool in the same script, which doesn't work. When I generate schema in other script and call diff tool on schemas later, it works.

Please, I'm willing to work on fix, but give me some ideas what should I try. (I thought about adding prefixes into php model files after they are copied into temp directory (to simulate YAML behavior), or bend the loading of models later, but I'm not sure the rest of code would cope with such fix, or there's more to do.



 Comments   
Comment by Peter Helcmanovsky [ 06/Sep/10 ]

Another potentional fix is to not copy model files into temp dir, but generate YAML from them, and then generate prefixed models trough YAML code path.
Doesn't sound effective, but as long as YAML path will be fixed, it may work?

Comment by Peter Helcmanovsky [ 08/Sep/10 ]

One more idea for how it can be done ( ? ):
to create temporary php script in temp dir together with from model files, run it, let it generate $fromInfo data, serialize them on disk, do the same with to models and get another serialized data, then load those files into $fromInfo and $toInfo and do the actual diffing.

The point is that by running the small temporary script in new process it would be able to load model files from disk as classes without prefixing/changing them, create the $info data, and exit, so the newer classes with same name can be loaded again in the another new thread. The diff then has to live with serialized $info data only without loading model classes.





[DC-858] Custom Behaviors/Templates cause autoloader errors Created: 04/Sep/10  Updated: 04/Sep/10

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

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

Windows Vista/7
PHP 5.3.1 - 5.3.3
Zend autoloader
not occuring under Ubuntu 10.05 / MacOSX



 Description   

When emitting Behaviors from schema files (YAML in our case),
Doctrine expects a shortened class name of the behavior (e.g. 'Timestampable') instead of the full class name:
The string 'Doctrine_Template_' is automatically prepended and a check (class_exists()) is made.

This is leading to possible autoloader errors (in our case: Zend autoloader does not find our custom behavior):

YAML:

{{
Person:
actAs: [SoftDelete, My_Doctrine_Template_CustomBehavior]
...
}}

'SoftDelete' is the short class name of 'Doctrine_Template_SoftDelete'.
'My_Doctrine_Template_CustomBehavior' is the full class name and shall not be prefixed with 'Doctrine_Template_'.

The corresponding section responsible for this bug:

File: Doctrine/Import/Builder.php
Lines: 702-704, function emitAssign()

{{
if (class_exists("Doctrine_Template_$name", true))

{ $classname = "Doctrine_Template_$name"; } }}

There is no test whether a full class name is given as $name, so there is no way to add custom behaviors to records without the autoloader checking for a non-existing class and spilling errors/notices.
With the above YAML schema file it would test for class_exists('Doctrine_Template_My_Doctrine_Template_CustomBehavior'), which is obviously not existing.

a quick fix could look like this:

{{
if (strpos($name, '_') === false // is this a shortened name of an original Doctrine behaviour class?
&& class_exists("Doctrine_Template_$name", true)) { $classname = "Doctrine_Template_$name";}}}

Another alternative (but breaking compatability with existing schema files) would be to always use full class names instead of fancy short names.

Interestingly enough, this error is only occuring with Zend autoloader on Windows systems, but can be easily avoided with the fix like suggested above.



 Comments   
Comment by Jonathan H. Wage [ 04/Sep/10 ]

I believe this is because the Zend autoloader does not fail silently by default. I think it can be configured to check if the file exists and not throw any errors.





[DC-856] Doctrine_Core::getPath() not working when inside phar, due to a bug in php Created: 03/Sep/10  Updated: 17/Apr/14

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

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


 Description   

It seems that there is a bug in php, and realpath doesn't work when path is inside of phar archive.
function Doctrine_Core::getPath()
if ( ! self::$_path)

{ self::$_path = realpath(dirname(__FILE__) . '/..'); }

can be easily changed to
if ( ! self::$_path)

{ self::$_path = dirname(dirname(__FILE__)); }

 Comments   
Comment by Pierre-Gildas MILLON [ 04/Jan/11 ]

http://bugs.php.net/bug.php?id=52769





[DC-854] having not work as expected and described Created: 02/Sep/10  Updated: 02/Sep/10

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

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


 Description   

$this->q1 = Doctrine_Query::create()
->select('m.questionaire')
->addSelect('m.aszero')
->addSelect('COUNT(f.id) as bref')
->from('machine m')
->leftJoin('m.relations r ON r.machine_id=m.id')
->leftJoin('r.ref f ON f.id=r.ref_id AND f.part_number LIKE "B%"')
->groupBy('m.questionaire')
->having('bref=0')
;
is producing

"SELECT m.id AS m_id, m.questionaire AS mquestionaire, m.aszero AS maszero, COUNT(r2.id) AS r2_0 FROM machine m LEFT JOIN relation r ON (r.machine_id = m.id) LEFT JOIN ref r2 ON ((r2.id = r.ref_id AND r2.part_number LIKE "B%")) GROUP BY m.questionaire HAVING bref=0 "

but it should be

"SELECT m.id AS m_id, m.questionaire AS mquestionaire, m.aszero AS maszero, COUNT(r2.id) AS r20 FROM machine m LEFT JOIN relation r ON (r.machine_id = m.id) LEFT JOIN ref r2 ON ((r2.id = r.ref_id AND r2.part_number LIKE "B%")) GROUP BY m.questionaire HAVING r2_0=0 "

http://www.doctrine-project.org/docu mentation/manual/1_1/en/dql-doctrine-query-language%3Agroup-by,-having-clauses

With kind regards

Petronel

I use symfony 1.4 and not sure if doctrine is 1...






[DC-853] I am using symfony 1.4 Created: 01/Sep/10  Updated: 02/Sep/10

Status: Reopened
Project: Doctrine 1
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Symfony 1.4



 Description   

$q1 = Doctrine_Query::create()
->select('m.questionaire, COUNT(f.id) AS bref')
->from('machine m')
->leftJoin('m.relations r ON r.machine_id=m.id')
->leftJoin('r.ref f ON r.ref_id=f.id AND f.part_number LIKE "B%"')
->groupBy('m.questionaire')
;
$r1 = $q1->execute();
$q1q = $q1->getSqlQuery();

$q2 = Doctrine_Query::create()
->select('m.questionaire, COUNT(f.id) AS nonbref')
->from('machine m')
->leftJoin('m.relations r ON r.machine_id=m.id')
->leftJoin('r.ref f ON r.ref_id=f.id AND f.part_number NOT LIKE "B%"')
->groupBy('m.questionaire')
;
$r2 = $q2->execute();
$q2q = $q2->getSqlQuery();

$this->reports->setQuery(Doctrine_Query::create()
->select('')
->from('(SQL:'.$q1q.'} q1')
->leftJoin('(SQL:'.$q2q.') q2 ON q1.questionaire=q2questionaire')
);
echo $this->reports->getQuery()->getSqlQuery(); die;

This outputs Couldn't find class (SQL

How to use in such a case ?



 Comments   
Comment by Jonathan H. Wage [ 01/Sep/10 ]

What is the SQL: syntax you are using here? That is definitely not something that is "supported"

Comment by Petronel MALUTAN [ 02/Sep/10 ]

Dear Jonathan

The example I've tried is based on the :
http://www.symfony-project.org/cookbook/1_2/en/retrieving_data_with_doctrine
Please find Sub-Queries in this article and see what I mean.

My problem started from a SQL query created in phpmyadmin, I've tried to convert to doctrine. Following is the mysql query which nicely work:

select * from (select m1.questionaire, COUNT(f1.id) AS n1_refs
from machine AS m1
left join relation AS r1 on m1.id=r1.machine_id
left join ref AS f1 on f1.id=r1.ref_id and f1.part_number LIKE 'B%'
group by m1.questionaire) as a1

left join

(select m2.questionaire, COUNT(f2.id) AS n2_refs
from machine AS m2
left join relation AS r2 on m2.id=r2.machine_id
left join ref AS f2 on f2.id=r2.ref_id and f2.part_number not LIKE 'B%'
group by m2.questionaire) as a2
on a1.questionaire=a2.questionaire

and my trying was to create 2 easier DQL queries and than join them:

$this->q = Doctrine_Query::create()
->select('')
;

$this->q1 = $this->q->createSubquery()
->select('m.questionaire, m.aszero, COUNT(f.id) AS bref')
->from('machine m')
->leftJoin('m.relations r ON r.machine_id=m.id')
->leftJoin('r.ref f ON f.id=r.ref_id AND f.part_number LIKE "B%"')
->groupBy('m.questionaire')
;
//$r1 = $q1->fetchArray();
//$this->r1=$this->q1->execute(array(),Doctrine_Core::HYDRATE_RECORD);

$this->q2 = $this->q->createSubquery()
->select('m.questionaire, m.aszero, COUNT(f.id) AS nonbref')
->from('machine m')
->leftJoin('m.relations r ON r.machine_id=m.id')
->leftJoin('r.ref f ON f.id=r.ref_id AND f.part_number NOT LIKE "B%"')
->groupBy('m.questionaire')
;
//$this->r2=$this->q2->execute(array(),Doctrine_Core::HYDRATE_RECORD);

$this->q->from($this->q1->getDql() . ' q1)')
>leftJoin($this>q2->getDql() . ' q2 ON q1.questionaire=q2questionaire');

echo $this->q->getSqlQuery(); die;

This is outputting :

500 | Internal Server Error | Doctrine_Exception
Couldn't find class SELECT

so please tell me is it now more clear and make some sense ?
How to make it work ?

With kind regards

Petronel

Comment by Jonathan H. Wage [ 02/Sep/10 ]

Can you make a test case that I can run on my machine to see the problem?





[DC-850] Error in Doctrine method execute() Created: 31/Aug/10  Updated: 31/Aug/10

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

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


 Description   

In the execute method when doctrine runs a sql query, the process is
interrupted. The review found that the process is interrupted in the fetch method in class Doctrine::Hidrator::Graph.php

In the line $stmt->fetch(Doctrine_Core::FETCH_ASSOC);

I appreciate the partnership that I can provide.

Thanks



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

Can you provide some more information?





[DC-849] Error Generate Schema.yml Database Oracle Created: 31/Aug/10  Updated: 31/Aug/10

Status: Open
Project: Doctrine 1
Component/s: Schema Files
Affects Version/s: 1.2.3
Fix Version/s: None

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

Ubuntu 10.4, Oracle



 Description   

Some deleted records are genereated by the Oracle driver, the following patch solves the problem, found with .... alexia.velasquez@hotmail.es, vtamara@pasosdeJesus.org, jeronimo0000@gmail.com

— Doctrine/Import/Oracle.php.orig 2010-08-31 11:01:10.934142453 -0500
+++ Doctrine/Import/Oracle.php 2010-08-31 11:01:35.778661707 -0500
@@ -118,7 +118,7 @@
SELECT tc.column_name, data_type,
CASE WHEN data_type = 'NUMBER' THEN data_precision ELSE data_length END AS data_length,
nullable, data_default, data_scale, data_precision, pk.primary
-FROM all_tab_columns tc
+FROM user_tab_columns tc
LEFT JOIN (
select 'primary' primary, cc.table_name, cc.column_name from all_constraints cons
join all_cons_columns cc on cons.constraint_name = cc.constraint_name
@@ -252,4 +252,4 @@
$query = 'SELECT view_name FROM sys.user_views';
return $this->conn->fetchColumn($query);
}
-}
\ No hay ningún carácter de nueva línea al final del fichero
+}



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

Hi, the formatting is a bit unreadable. Can you fork http://github.com/doctrine/doctrine1 and send a pull request?





[DC-847] Can not set a default value of 'CURRENT_TIMESTAMP' in a table definition for mysql Created: 31/Aug/10  Updated: 25/Sep/10

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

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

XAMP Windows


Attachments: Text File DC_847_fix.patch     Text File DC_847_fix_BC.patch    

 Description   

Hi

I recently I discovered that I needed o put a default value of 'CURRENT_TIMESTAMP' on some of my fields. This was breaking the build of my mysql base for 2 different reasons – for one columns with a type of timestamp were being switched instead to have a type of datetime, and for two the words: CURRENT_TIMESTAMP were being quote encapsulated in the create table statement.

I looked around a bit and couldn't find a solution so I made a patch to fix the issue. This patch however broke some test cases that were expecting datetimes to be returned instead of timestamps (so i fixed the tests).

I may be breaking something that I am not aware of by doing this, or perhaps there was another solution to the problem that I could not find – if any one has any input on this I would appreciate it.

I will post my patch in this thread but it is worth mention that it contains several bug fixes and a few new features which I have posted in other threads several months ago but never heard back regarding (most notably, beyond bug fixes it introduces a new hydration type and allows the disabling of the some times useful some times problematic limit subquery feature of doctrine).

Thanks to all who have any input.

Will Ferrer



 Comments   
Comment by will ferrer [ 31/Aug/10 ]

Here is the patch

Comment by will ferrer [ 01/Sep/10 ]

Found a small error in my last patch (some debug code I hadn't removed) and added some more comments (links to jira above each change) to clarify the fixes and new features the patch has in it.

Comment by will ferrer [ 01/Sep/10 ]

individual patch for this issue with out other features included

Comment by Jonathan H. Wage [ 02/Sep/10 ]

Hi, this one breaks the tests and backwards compatibility. Previously if you have a timestamp field in Doctrine, it would create a datetime column in mysql. Now it is creating a timestamp column. I don't think we can make this change in a stable version.

Comment by Jonathan H. Wage [ 02/Sep/10 ]

At any rate, it is breaking the tests still. If we do decide to make the change, can you run all the tests and fix any of the other failures?

Comment by will ferrer [ 02/Sep/10 ]

Hi Jon

I added more test case fixes to the patch. I can see how this would still cause backwards compatibility issues though – any one who built their db using the none patched version of doctrine would end up with different field types if they rebuilt using the patched version and this could affect the functionality of their existing code.

Thanks for the help .

Hope you are well.

Will

Comment by Jonathan H. Wage [ 03/Sep/10 ]

Can you think of anyway it could be tweaked so that it is BC?

Comment by will ferrer [ 03/Sep/10 ]

Good question...

Here is an idea – how about I put a flag in the options for the field that changes the behavior. So if some one wants to use real timestamps instead of datetime fields they could set an option of: "useRealTimestamps : true" on the field.

I think that would be a good solution because by default everything would work as does is now (providing BC) but users could switch it over if they required the additional functionality that timestamps provide.

What do you think?

Will

Comment by will ferrer [ 11/Sep/10 ]

Hi Jon

Here is a backwards compatible patch using the method I proposed in my last comment.

To make a timestamp field use a type of timestamp (instead of datatime) include an option of: userealtimestamp=>true

Let me know if you think this method will work out.

Hope you are well.

Will

Comment by will ferrer [ 25/Sep/10 ]

I found some issues with this patch when I moved it off my local machine our production server – there was a case sensitivity issue that I have since resolved. Here is the fixed version.





[DC-845] One of our Foreign Keys is not being inserted/passed Created: 27/Aug/10  Updated: 27/Aug/10

Status: Open
Project: Doctrine 1
Component/s: Record, Relations, Transactions
Affects Version/s: 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

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

Linux ubuntu 2.6.31-22-generic #63-Ubuntu SMP Thu Aug 19 00:23:50 UTC 2010 x86_64 GNU/Linux
PHP 5.2.10-2ubuntu6.4 with Suhosin-Patch 0.9.7 (cli) (built: Jan 6 2010 22:56:44)
mysql Ver 14.14 Distrib 5.1.37, for debian-linux-gnu (x86_64) using EditLine wrapper



 Description   

We are working on a symfony/doctrine project and have come to a near halt on development.

We feel that now, it may be a bug/feature in doctrine, regarding foreign keys

Part of our model includes a join table that references three different table. Below is a diagram of what the model looks like, and the relevant portion of our schema.yml is at the bottom.

Image of our schema: http://imgur.com/dfFYI.png

We have a form that contains a set of embedded forms that attempt to create a new Person entry and add rows to the join table, adding items to the PersonName table as needed.

The form attempts to do this by creating and saving PersonName objects with NameType parameters, but are running into the problem of Doctrine not including that column when trying to do an insert into the join table.

Part of the problem seems to be caused by the Doctrine_Connection_UnitOfWork::saveAssociations method:

foreach ($v->getInsertDiff() as $r)

{ $assocRecord = $assocTable->create(); $assocRecord->set($assocTable->getFieldName($rel->getForeign()), $r); $assocRecord->set($assocTable->getFieldName($rel->getLocal()), $record); $this->saveGraph($assocRecord); }

Are we correct in understanding that this means that Doctrine 1.2 does not support tables with multiple foreign keys in this scenario?

Here is the relevant portion of schema.yml:

agPerson:
columns:
id:
primary: true
type: integer(5)
autoincrement: true
relations:
agPersonName:
class: agPersonName
refClass: agPersonMjAgPersonName
local: person_id
foreign: person_name_id
agPersonNameType:
class: agPersonNameType
refClass: agPersonMjAgPersonName
local: person_id
foreign: person_name_type_id
agPersonNameType:
columns:
id:
primary: true
type: integer(2)
autoincrement: true
person_name_type:
unique: true
type: string(30)
notnull: true
app_display:
default: 1
type: boolean
notnull: true
relations:
agPerson:
class: agPerson
refClass: agPersonMjAgPersonName
local: person_name_type_id
foreign: person_id
agPersonName:
class: agPersonName
refClass: agPersonMjAgPersonName
local: person_name_type_id
foreign: person_name_id
agPersonName:
columns:
id:
primary: true
type: integer(5)
autoincrement: true
person_name:
unique: true
type: string(64)
notnull: true
relations:
agPerson:
class: agPerson
refClass: agPersonMjAgPersonName
local: person_name_id
foreign: person_id
agPersonNameType:
class: agPersonNameType
refClass: agPersonMjAgPersonName
local: person_name_id
foreign: person_name_type_id
agPersonMjAgPersonName:
columns:
id:
primary: true
type: integer(5)
autoincrement: true
person_id:
type: integer(5)
notnull: true
person_name_id:
type: integer(5)
notnull: true
person_name_type_id:
type: integer(2)
notnull: true
is_primary:
type: boolean
notnull: true
indexes:
UX_ag_person_mj_ag_person_name:
fields: [person_name_id, person_name_type_id, person_id]
type: unique
relations:
agPerson:
local: person_id
foreign: id
agPersonName:
local: person_name_id
foreign: id
agPersonNameType:
local: person_name_type_id
foreign: id
actAs:
Timestampable:

As a caveat: we've noticed that sfdoctrineguard group table, has such a relationship:

mysql> describe sf_guard_user_group;
---------------------------------------+

Field Type Null Key Default Extra

---------------------------------------+

user_id int(11) NO PRI 0  
group_id int(11) NO PRI 0  
created_at datetime NO   NULL  
updated_at datetime NO   NULL  

---------------------------------------+

i.e. IT has two foreign keys taken into account






[DC-844] DataDict for MySQL excludes the possibility to have an actual floating point column Created: 27/Aug/10  Updated: 27/Aug/10

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

Type: Bug Priority: Major
Reporter: Roberto González Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Not environment dependent



 Description   

Extracted from Doctrine/DataDict/Mysql.php:

Mysql.php
            case 'float':
                $length = !empty($field['length']) ? $field['length'] : 18;
                $scale = !empty($field['scale']) ? $field['scale'] : $this->conn->getAttribute(Doctrine_Core::ATTR_DECIMAL_PLACES);
                return 'FLOAT('.$length.', '.$scale.')';
            case 'double':
                $length = !empty($field['length']) ? $field['length'] : 18;
                $scale = !empty($field['scale']) ? $field['scale'] : $this->conn->getAttribute(Doctrine_Core::ATTR_DECIMAL_PLACES);

If the user does not specify length and decimal places, MySQL creates a floating point number. However Doctrine behavior forces FLOATs and DOUBLEs to be fixed-width.






[DC-842] Alias linking wrong Created: 26/Aug/10  Updated: 26/Aug/10

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

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


 Description   

When you create this kind of query:
$q = Doctrine_Query::create()
->select( 'p.name, a.key, count( a.key ) as amount' )
->from( 'Actions a, ActionPage p' )
->where( 'a.key = p.id' )
->andWhere( 'a.type = 1' )
->andWhere( 'p.type = 2' )
->andWhere( 'a.date >= 0' )
->andWhere( 'p.name not like \'%&ru=%\'' )
->groupBy( 'a.key' )
->orderBy( 'amount' )
->execute( array(), Doctrine::HYDRATE_ARRAY );

You get the folowing error:
Fatal error: Uncaught exception 'Doctrine_Hydrator_Exception' with message '"ActionPage" with an alias of "p" in your query does not reference the parent component it is related to.

There is no relation between those 2 tables. You can solve it by creating a default SQL query. But my guess is that this shouldn't be the right way.






[DC-841] Doctrine_Connection_Mssql::replaceBoundParamsWithInlineValuesInQuery regex failing to replace all '?' instances [patch+] Created: 25/Aug/10  Updated: 05/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Connection
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Daniel Cousineau Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 3
Labels: None
Environment:

PHP 5.2.11, Apache, Microsoft SQL Server 2005



 Description   

When executing queries with WHERE statements using multiple instances of the "<>" operator (as well as other non =,( symbols inbetween definitions), the method Doctrine_Connection_Mssql::replaceBoundParamsWithInlineValuesInQuery fails to identify all ? replacements.

In the following piece of code I have a query (trimmed for readability and renamed for privacy) that fails to have all "?" symbols replaced as well as the relevant code from the method mentioned above (minus the return statement) doing a simple demonstration:

<?php 
$query = "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <> ? AND [t].[field2] <> ? AND [t].[field2] LIKE ?)";

$params = array(
	"'param1'",
	"'param2'",
	"'param3'"
);


/**
 * Replaces bound parameters and their placeholders with explicit values.
 *
 * Workaround for http://bugs.php.net/36561
 *
 * @param string $query
 * @param array $params
 */
//protected function replaceBoundParamsWithInlineValuesInQuery($query, array $params) {

	foreach($params as $key => $value) {
		if(is_null($value)) {
			$value = 'NULL';
		}
		else {
			//$value = $this->quote($value); //REMOVED AS PRE-ADDED QUOTES TO ABOVE PARAMETER LIST
		}

		$re = '/([=,\(][^\\\']*)(\?)/iU';
		
		$matches = array();
		preg_match($re,$query,$matches);
		
		var_dump($matches); //ADDED FOR DEMONSTRATION

		$query = preg_replace($re, "\\1 {$value}", $query, 1);
		
		var_dump($query); //ADDED FOR DEMONSTRATION
	}

//	return $query;
//
//}

Running this code produces:

array(3) {
  [0]=>
  string(18) "([t].[field1] <> ?"
  [1]=>
  string(17) "([t].[field1] <> "
  [2]=>
  string(1) "?"
}
string(108) "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <>  'param1' AND [t].[field2] <> ? AND [t].[field2] LIKE ?)"
array(0) {
}
string(108) "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <>  'param1' AND [t].[field2] <> ? AND [t].[field2] LIKE ?)"
array(0) {
}
string(108) "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <>  'param1' AND [t].[field2] <> ? AND [t].[field2] LIKE ?)"

Unfortunately the regex will not identify all the ? instances properly in the query when run like preg_match_all(), which was my first idea to fix (pre-identify all ? instances, then go through and replace them).

The only 3 potential solutions I can think of are:

1. Pre-identify all ?'s and note their position in the string, to do this using a much looser regex, then replace all the ?'s found
2. Use a stack a loop and a switch statement to scan for eligible ? replacements. I have some sample code that shows this should work, but performance is not something I have tested.
3. Revert back to the previous behavior. Scanning the changelogs I really don't know where this broke, other than queries that worked prior to 1.2.3 have since broken and this method is the cause.



 Comments   
Comment by Daniel Cousineau [ 25/Aug/10 ]

I am probably way over thinking a solutions, however since I have to run home and don't have time to flesh this out further at the moment, my initial idea is something like this:

<?php 
$query = "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <> 'Testing!?' AND [t].[field2] <> ? AND [t].[field?] LIKE ? AND [t].[field3] = ?)";

$params = array(
	"'param1'",
	"param2?",
	"'param3'"
);

var_dump($query);

$stack = array();
$stringDelim = array("'", '"');

$i = 0;
foreach( str_split($query) as $char )
{
	switch($char) {
		
		case "[":
			if( !in_array(end($stack), $stringDelim) )
				array_push($stack, $char);
			
			break;
			
		case "]":
			if( end($stack) == "[" ) {
				array_pop($stack);
			} else
				array_push($stack, $char);
				
			break;
		
		case "\"":
		case "'":
			if( end($stack) == $char )
				array_pop($stack);
			else
				array_push($stack, $char);
			
			break;
		
		case "?":
			if( !in_array(end($stack), array_merge($stringDelim, array("[", "]"))) )
			{
				$param = array_shift($params);
				$query = substr_replace($query, $param, $i, 1);
				
				$i += strlen($param) - 1;
				var_dump($query);
			}
			
			
			break;
		
		default:
	}
	
	$i++;
}

var_dump($query);

Which produces

string(131) "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <> 'Testing!?' AND [t].[field2] <> ? AND [t].[field?] LIKE ? AND [t].[field3] = ?)"
string(138) "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <> 'Testing!?' AND [t].[field2] <> 'param1' AND [t].[field?] LIKE ? AND [t].[field3] = ?)"
string(144) "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <> 'Testing!?' AND [t].[field2] <> 'param1' AND [t].[field?] LIKE param2? AND [t].[field3] = ?)"
string(151) "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <> 'Testing!?' AND [t].[field2] <> 'param1' AND [t].[field?] LIKE param2? AND [t].[field3] = 'param3')"
string(151) "SELECT * FROM [table] AS [t] WHERE ([t].[field1] <> 'Testing!?' AND [t].[field2] <> 'param1' AND [t].[field?] LIKE param2? AND [t].[field3] = 'param3')"

Which is what we would expect, as well as it doesn't take into account for newly inserted data containing '?' symbols.

But again this is just playing around with potential solutions.

Comment by Enrico Stahn [ 27/Aug/10 ]

The patch for DC-545 broke some queries or didn't worked at all. Unfortunately there was no Test Case for DC-545.

The patch and a Test Case can be found at: http://github.com/estahn/doctrine1/compare/master...DC-841

Comment by Enrico Stahn [ 02/Sep/10 ]

I made a mistake with github, the updated branch can be found at
http://github.com/estahn/doctrine1/tree/DC-841-2

Comment by Lionel ROTA [ 05/Mar/11 ]

Doesn't work with :

'Test' <> 'Test !?'

The question mark is captured...

This code seems working :

foreach($params as $key => $value) {
  if(is_null($value)) {
    $value = 'NULL';
  }
  else {
    $value = $this->quote($value);
  }

  $re = '/((?:[=<>,\(]|LIKE|IS)[^\\\']*)(\?)/iuU';

  $query = preg_replace($re, "\\1 {$value}", $query, 1);
}




[DC-838] "Primary columns are implied to be notnull in Doctrine" but are not Created: 24/Aug/10  Updated: 24/Aug/10

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

Type: Bug Priority: Major
Reporter: Jonathan Melnick (Doghouse Media) Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Latest doctrine git commit: bfa24eb68640c412ff6115103ba044bbe1b4333b
Ubuntu 10.4 x64
MySQL server 5.1.41-3ubuntu12.6
PHP 5.3.2



 Description   

Doctrine says : "Primary columns are implied to be notnull in Doctrine" (line 563 in lib/Doctrine/Import/Builder.php)

But when generating (My)SQL statements, primary fields are not set to "NOT NULL" even if it is specified in the YAML and/or Model file.

If doctrine unsets the 'notnull' option on line 565 in lib/Doctrine/Import/Builder.php (as it does), it should make sure to add the "NOT NULL" to the SQL when appropriate :

  • in getNotNullFieldDeclaration() method (line 798) in lib/Doctrine/Export.php
    AND
  • in getDeclaration() method (line 272) in lib/Doctrine/Export/Mysql.php

Solution #1: In both places, check if field is primary, and if so, add "NOT NULL" to SQL, since "Primary columns are implied to be notnull in Doctrine".

Solution #2: Change Doctrine as to not enforce this behaviour (eg. remove the check in lib/Doctrine/Import/Builder.php on line 565)

Thx for this great ORM.

~ Jonathan






[DC-837] Add support for AFTER in migration addColumn function Created: 23/Aug/10  Updated: 23/Aug/10

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

Type: New Feature Priority: Major
Reporter: Exien Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It's imperative that the migration utility support specifying where the column is created and not just created at the end of the table, otherwise the migration utility is pretty much useless. I want to keep my database schema clean and tidy.

I would say the default use case of this method is to specify where the new column is created.

Please add the ability to specify where the new column goes to this function:
Doctrine_Migration::addColumn().



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

I understand your desire to want to control where a column is added but to use words like "imperative" and "useless" is crazy! Where the column goes is in no way a blocker or major problem. If someone wants this bad enough and provides a patch we can consider including it.





[DC-835] Inconsistent record validation on a notnull foreign key when the local relation is set Created: 19/Aug/10  Updated: 24/Aug/10

Status: Open
Project: Doctrine 1
Component/s: Record, Relations, Validators
Affects Version/s: 1.2.1
Fix Version/s: None

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

Attachments: Text File dc-835-patch.txt     File ForeignKeysTestCase.php    

 Description   

Doctrine_Validator_ForeignKeys_TestCase#testForeignKeyIsValidIfLocalRelationIsSet()

This test passes fine as is. But it fails if I make the following change:

public function testForeignKeyIsValidIfLocalRelationIsSet()
{
    //$person = new TestPerson();
    $address = new TestAddress();
        
    //$address->Person = $person;    
    $address->Person->first_name = "John";
        
    $table = $address->getTable();
    $errors = $table->validateField('person_id', $address->person_id, $address);
        
    $this->assertEqual(0, $errors->count());
}

The only difference is that instead of explicitly assigning $address->Person, I'm letting it happen automatically when assigning the first name. What is it about the property chaining when creating the related record that screws up doctrine's internal reference tracking?



 Comments   
Comment by Adam Huttler [ 19/Aug/10 ]

This is an existing test case for which I've added two tests. The first one fails, while the second passes. The first one captures the issue I'm experiencing.

Comment by Adam Huttler [ 24/Aug/10 ]

This patch augments the test file with the new test and also makes a change to Doctrine_Related_LocalKey that causes the test to pass.

Unfortunately, it causes another test to fail: 1072.

I don't fully understand test 1072, but it appears to be testing closely related behavior (i.e. relation chaining).

What do you think?





[DC-834] When altering an existing column PGSQL can't convert to SERIAL for autoincrement Created: 18/Aug/10  Updated: 18/Aug/10

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

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

PostgreSQL 8.4



 Description   

If you have an existing column Postgresql won't allow you to use the type SERIAL for altering the column.

First create a column cat_id on category of integer type. Then run the following migration:

migration.php
    public function up()
    {
        $this->changeColumn('category', 'cat_id', 'integer', '4', array(
             'unsigned' => '',
             'primary' => '1',
             'autoincrement' => '1',
             ));
    }

Instead of using type SERIAL doctrine would have to simply alter the column then add a sequence on it's own.






[DC-833] Data type in YAML schema spacing issue Created: 18/Aug/10  Updated: 18/Aug/10

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

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

Windows 7, Apache 2.2.11, PHP 5.2.9, MySQL 5.1.36



 Description   

When creating a column in a table in a YAML schema file, the following two scenarios produce different results:

Model:
columns:
...
some_numeric:
type: integer(3)
....
__________________________
Model:
columns:
...
some_numeric:
type: integer (3)
....

Please note the spacing in the second example before the (3) in the type definition. The first example will generate a mediumint in MySQL with a length other than 3, while the second example works as expected.



 Comments   
Comment by Danny Kopping [ 18/Aug/10 ]

The formatting for the YAML didn't come out right through JIRA, I apologize for that





[DC-831] Importing fixtures fails when GoogleI18n used with "Couldn't create collection index. Record field 'lang' was null." Created: 17/Aug/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures, I18n, Import/Export
Affects Version/s: 1.2.2, 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: