[DC-1006] Custom geometric query error with orderBy Created: 22/May/11  Updated: 22/May/11

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

Type: Bug Priority: Minor
Reporter: Leonardo Lazzaro Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Symfony 1.4.11 and Doctrine 1.2.4. Ubuntu 11.04 Apache2 with mod php5. php5 version PHP 5.3.5-1ubuntu7.2 with Suhosin-Patch



 Description   

Mi Doctrine_Query with this Geometric Query fails with orderBy , but with where works.

$distance = "glength(linestringfromwkb(linestring(GeomFromText('POINT( ".$object->getLatitude()." ".$object->getLongitude() .")'),l.point))) "

This works:
SomeObjectTable::getInstance()>createQuery()>where($distance.' < ?',0.05 )

But this one fails at version 1.2.4, with older version was working.
SomeObjectTable::getInstance()>createQuery()>where($distance.' < ?',0.05 )->orderBy($distance)

Well the problem is at line 74 of OrderBy.php :
$componentAlias = implode('.', $e);

the rendered query in the distance has some ".", for example:
POINT( -34.470829 -58.5286102)

then the after line 74 in OrderBy tries to search por '58' class.

I manually added to DataDict in Mysql.php the POINT datatype (this fix solve me the problem in older versions of Doctrine).






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

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

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

all



 Description   

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

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

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



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

Length of the i18n column is configurable...





[DC-803] Syntax error in MySQL migration to drop constraint (patch supplied) Created: 29/Jul/10  Updated: 29/Jul/10

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

Type: Bug Priority: Minor
Reporter: Gavin Davies Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Debian, PHP 5.3.2, MySQL


Attachments: Text File SyntaxFixForMySQLDropConstraintInExport.patch    

 Description   

I have a migration that adds constraints correctly. When migrating down, however, I get a syntax error

ErrorMessage
  Error #1 - 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 'CONSTRAINT unique_username_idx' at line 1. Failing Query: "ALTER TABLE conUser DROP CONSTRAINT unique_username_idx"

Here is the down migration:

DownMigration
    public function down() {
        $this->dropConstraint('conUser', 'unique_username_idx');
    }

The SQL generated is "ALTER TABLE conUser DROP CONSTRAINT unique_username_idx". This post (http://forums.mysql.com/read.php?98,70887,70974#msg-70974) suggests that in MySQL the syntax should be "ALTER TABLE conUser DROP INDEX unique_username_idx" as constraints are basically indexes in MySQL (unlike MSSQL and Oracle). Doctrine's lib/Doctrine/Export/MySql.php appears to have a syntax error in the dropConstraint method. I attach a patch for this, but the only change is replacing "$name = 'CONSTRAINT '" with "$name = 'INDEX '" in dropConstraint. The migration then runs as I would expect.

Sorry if this has been fixed elsewhere, I did a search but couldn't find a similar ticket.



 Comments   
Comment by Gavin Davies [ 29/Jul/10 ]

fixing syntax





[DC-799] Doctrine_Query::parseFunctionExpression() produces unexpected results if the expression contains a function Created: 27/Jul/10  Updated: 27/Jul/10

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

Type: Bug Priority: Major
Reporter: Henning Glatter-Gotz Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mac OS X, LINUX



 Description   

When Doctrine_Query::parseFunctionExpression() is called with the following parameter and $this->_conn->expression is of type Doctrine_Expression_MySql:

$expr = "DATE_FORMAT(datefield,'%Y-%m-%d'),someotherfield"

The expected result from Doctrine_Query::parseFunctionExpressoin() would be

DATE_FORMAT(l.datefield,'%Y-%m-%d'),l.someotherfield

However, the actual result is

DATE_FORMAT(l.datefield,'%Y-%m-%d'),someotherfiel

Note the missing leading "l." and the last character ("d") on "someotherfield".
Obviously this leads to fatal errors.

This example is a result of calling addGroupby("DATE_FORMAT(datefield,'%Y-%m-%d'),someotherfield") on a Doctrine_Query object.






[DC-795] Can't mix Soft and Hard deletes. Fix with patch provided. Created: 21/Jul/10  Updated: 21/Jul/10

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

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

Mac



 Description   

I reported this bug on the symfony site, but after investigation i have found that it is actually a doctrine SoftDelete issue. http://trac.symfony-project.org/ticket/8898

I have a sandbox replicating the problem here:
http://dl.dropbox.com/u/8354765/sf_sandbox.zip

Run the test:
./symfony test:unit Contact

The issue is I want to hard delete my M-M link table and soft delete the parents. This fails. I believe it is to do with the fact that the relations to the parent are marked as Doctrine_Record::STATE_TCLEAN which when the SoftDelete calls save on the parent object this flag trys to reinsert the relations that it has deleted. Things go very wrong at this point and the connection is rolled back.

The fix I have is the following, not sure what this would do to other things or not as I am not overly familiar with Doctrine internals...

Index: Doctrine/Template/Listener/SoftDelete.php
===================================================================
--- Doctrine/Template/Listener/SoftDelete.php	(revision 12962)
+++ Doctrine/Template/Listener/SoftDelete.php	(working copy)
@@ -95,6 +95,7 @@
     public function postDelete(Doctrine_Event $event)
     {
         if ( ! $this->_options['hardDelete']) {
+            $event->getInvoker()->clearRelated();
             $event->getInvoker()->save();
         }
     }

This works even if the relations have been marked as SoftDelete.



 Comments   
Comment by John Wards [ 21/Jul/10 ]

Formatting

Comment by Jonathan H. Wage [ 21/Jul/10 ]

Does this patch pass the test suite?

Comment by John Wards [ 21/Jul/10 ]

I have run the test suite and got the same 8 failures with and without the patch.

These are the failing tests:
Doctrine_Cache_Apc_TestCase
Doctrine_Cache_Abstract_TestCase
Doctrine_Ticket_1783_TestCase

Anything obvious I need to do to get these working, other than enabling apc...

Comment by John Wards [ 21/Jul/10 ]

It seems to be passing all the tests that have SoftDelete in them however, so I would say that it is working as expected.





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

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

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

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



 Description   

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

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

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

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

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

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



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

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





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

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

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

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


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

 Description   

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

This of course blows up my inserts.

I have included the following documentation:

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

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



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

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

./symfony doctrine:build-sql

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

This is Postgres.

Comment by Dennis Gearon [ 25/Jun/10 ]

So much for getting around this problem easily,

I tried doing this:

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

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

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

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

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

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

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

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

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

Comment by Dennis Gearon [ 25/Jun/10 ]

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

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

Comment by Dennis Gearon [ 25/Jun/10 ]

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

Comment by Dennis Gearon [ 25/Jun/10 ]

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

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

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





[DC-753] doctrine generate-migrations-diff throws "No php or yml files found at path" Created: 19/Jun/10  Updated: 27/Jan/11

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

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

WIndows 7 x64, WAMP, PHP 5.2.11 & 5.3



 Description   

I am trying to generate migrations from the CLI but I get the error mentioned in the title. I did some searching and this seems to have been a known problem and was fixed, however, I'm getting it and the path is correct, and there is even a schema.yml file I just generated, also through CLI.

Here is the error:

D:\wamp\www\project\src\administrator\components\com_project\doctrine>php doctrine generate-migrations-diff
No php or yml files found at path: "D:\wamp\www\project\src\administrator\components\com_project\doctrine\schema"

And here is what I have in my CLI file:

require_once('../../../../libraries/doctrine/lib/Doctrine.php');

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

Doctrine_Manager::connection('mysql://root@localhost/project','default');

//Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_TBLNAME_FORMAT, 'jos_project_%s');
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_VALIDATE, Doctrine::VALIDATE_ALL);
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_QUOTE_IDENTIFIER, true);
Doctrine::loadModels('models/generated');
Doctrine::loadModels('models');

$cli = new Doctrine_Cli(array(
'data_fixtures_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'fixtures',
'models_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'models',
'migrations_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'migrations',
'sql_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'sql',
'yaml_schema_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'schema'
));

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

I find this very weird because earlier today I was able to make a migration the same way but with Symfony's CLI, however, that is another project.

Regards,

David



 Comments   
Comment by Marcelo Saldanha [ 27/Jan/11 ]

I have the same problem, using symfony 1.4 latest sources. After reading about 20 (long) pages about similar issues, I've come up with a solution.

The problem appears when the project still don't have any Models defined. Im my case, they were all new projects in the plugin activation stage. Curiously, the behaviour were random, as in some projects I could activate my Contacts plugin (the first), and in others I couldn't.

After much consideration, the problem was that the var $extension in /doctrine/Doctrine/Migration/Diff.php was empty, and that was because the algorithm only considered the first entry of the directory. If it was a file, its extension was used. If not, the algorithm descended until it found a file as the first entry. BUT it never considered second (and following) entries, so as my first entry was the 'base' directory, and it was empty, no extension was ever found. This probably will not happen if the project have some models defined.

And so, I came up with a solution. In doctrine/Doctrine/Migration/Diff.php, enclose this code in the _getItemExtension method (near line 350, in my copy) with a loop, such as:
$idx = 0;
while (strlen($extension) == 0) {
if (isset($files[$idx])) {
if (is_dir($files[$idx]))

{ $extension = $this->_getItemExtension($files[$idx]); }

else

{ $pathInfo = pathinfo($files[$idx]); $extension = $pathInfo['extension']; }

$idx++;
}
else break; // no more entries to seek
}

Now it keep looking in every folder until it finds a file WITH an extension, and stops when all the tree is searched.

Hope that helps someone.

best regards.





[DC-740] issue with multiple connection handling Created: 16/Jun/10  Updated: 16/Nov/10

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

Type: Bug Priority: Major
Reporter: Ian P. Christian Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 3
Labels: None

Attachments: Text File doctrine_core.patch     Text File doctrine_manager.patch    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
DC-618 [PATCH] Local key relations without m... Sub-task Open Jonathan H. Wage  

 Description   

I've found an issue where doctrine will use the wrong connection for tables under certain conditions.

In a template, I'm doing a $sf_user->hasCredential() - which is causing this to be run in sfGuardSecurityUser,

$this->user = Doctrine::getTable('sfGuardUser')->find($id);

When this execute, the calls find themselves to Doctrine_Manager::getConnectionForComponent($componentName)

This method calls Doctrine_Core::modelsAutoload($componentName);, which fails to load the class, and returns false (no checking is done to see if it should return true).

As this fails to include the sfGuardUser classes wher the component binding goes on, the getTAble call will use the default connection, then create the table fails to use the correct connection

Doctrine_Core::getTable()

return Doctrine_Manager::getInstance()->getConnectionForComponent($componentName)->getTable($componentName);

the binding is done after the call to getConectionForComponent, as it's getTable that will ultimately cause the autoloader to pull in the table classes.



 Comments   
Comment by Jonathan H. Wage [ 16/Jun/10 ]

Hmm, why is the autoloading of sfGuardUser failing? I don't understand that part. If it is failing do you get a cannot load class error?

Comment by Ian P. Christian [ 16/Jun/10 ]

The reason no autoload error is throw, is because symfony's autoloader loads the class for you, but it does it at the getTable() call, which as seen below from Doctrine_Core::getTable(), it's proxied though the connection - which is created before the gable is instanced, which of when the file is actaully loaded.

return Doctrine_Manager::getInstance()->getConnectionForComponent($componentName)->getTable($componentName);
Comment by Ian P. Christian [ 16/Jun/10 ]

Just to expand on this...

This obviously gets called when a call to getTable is made:

    public function getConnectionForComponent($componentName)
    {
        Doctrine_Core::modelsAutoload($componentName);

        if (isset($this->_bound[$componentName])) {
            return $this->getConnection($this->_bound[$componentName]);
        }

        return $this->getCurrentConnection();
    }

The autoload fails, as you can see from the code...

    public static function modelsAutoload($className)
    {
        if (class_exists($className, false) || interface_exists($className, false)) {
            return false;
        }

        if ( ! self::$_modelsDirectory) {
            $loadedModels = self::$_loadedModelFiles;

            if (isset($loadedModels[$className]) && file_exists($loadedModels[$className])) {
                require $loadedModels[$className];

                return true;
            }
        } else {
            $class = self::$_modelsDirectory . DIRECTORY_SEPARATOR . str_replace('_', DIRECTORY_SEPARATOR, $className) . '.php';

            if (file_exists($class)) {
                require $class;

                return true;
            }
        }
        return false;
    }

$_modelsDirectory is never set, and $_loadedModelFiles is an empty array. The $_modelsDirectory, even if set, wouldn't handle loading for plugins, which put their models in places like lib/model/doctrine/sfDoctrineGuardPlugin/sfGuardUser.class.php.

Comment by Ian P. Christian [ 16/Jun/10 ]

This was not a problem before r7668 (at least, not for most use cases)....

It used to be that null was passed as the first arg in the D_Query::create() method call, causing the query to figure out itself which connection to use, which was done after the component was bound, so that's fine!

However, the code below is how it is in the current head

    public function createQuery($alias = '')
    {
        if ( ! empty($alias)) {
            $alias = ' ' . trim($alias);
        }

        $class = $this->getAttribute(Doctrine_Core::ATTR_QUERY_CLASS);

        return Doctrine_Query::create($this->_conn, $class)
            ->from($this->getComponentName() . $alias);
    }

Here , the connection of the table (as explained above is previously set incorerctly) is passed to the query.

Comment by Ian P. Christian [ 16/Jun/10 ]

I've found a work around to this, not sure if it's a desirable fix though...

In the project configuration class, I've added this to the setup()

    $this->dispatcher->connect('doctrine.configure', array($this, 'doctrineBinder'));

and the following method is also added, were I'm manually doing my bindings...

  public function doctrineBinder(sfEvent $event)
  {
    $manager = Doctrine_Manager::getInstance();
    $manager->bindComponent('sfGuardUser', 'nosp');
    $manager->bindComponent('Incident', 'nosp');
    $manager->bindComponent('ServiceIp', 'ip');

  }

The overhead here isn't really that high (it just sets an element in the array) - I'd also wonder if a bindComponents($array); should be added to simplify this call, but that's another method.

Comment by Marcel Berteler [ 06/Jul/10 ]

After a long and hard look at the sfDoctrinePlugin and Doctrine code I can to the same conclusion. The Doctrine autoload is not working in sfDoctrinePlugin. I think this is more a sfDoctrinePlugin bug than a Doctrine bug.

Instead of manual binding, a better way is the actually make sure the intended flow of the code is working like it should be.

To be able to use sfDoctrineGuard with multiple connections you need to ensure that the connection name is added to the Schema of sfDoctrineGuard. Once this is done, rebuilding the model will put a bindComponent in the class files.

This works fine if the autoload is working like it should.

To get the autoload to work, you can extend the autoload function of Doctrine_Core in Doctrine:

The Doctrine.php file is empty by default, so its easy to add your code to it (until the problem is fixed without having to edit Doctrine code)

lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine.php:

 
class Doctrine extends Doctrine_Core
{
  public static function modelsAutoload($className)
  {
    sfAutoload::getInstance()->autoload($className);

    parent::modelsAutoload($className);
  }
  
}
Comment by Marcel Berteler [ 06/Jul/10 ]

Sorry... the above does not work.

Doctrine_Core->autoload() is called and not Doctrine->autoload().

sfAutoload::getInstance()->autoload($className);

can be added to Doctrine_Core line 1133

public static function modelsAutoload($className)
    {
        if (class_exists($className, false) || interface_exists($className, false)) {
            return false;
        }

        sfAutoload::getInstance()->autoload($className);
Comment by Marcel Berteler [ 06/Jul/10 ]

Oh, and to make sfDoctrineGuard work properly, you might have to ensure the sfBasicSecurityUser is bound to the correct model.

You can do this in plugins\sfDoctrineGuardPlugin\lib\user\sfGuardSecurityUser.class.php or in apps\xxxxx\lib\myUser.class.php

 
Doctrine_Manager::getInstance()->bindComponent('sfGuardUser', 'connectionName');
Comment by Marcel Berteler [ 07/Jul/10 ]

The patch to Doctrine_Core

This is a hack that only works when used in sfDoctrinePlugin / Symfony

Not intended as the final patch to fix this bug but as a work around to make multiple connections usable.

Comment by Ian P. Christian [ 08/Jul/10 ]

This effects migrations too it seems:

Even doing this:

    $manager = Doctrine_Manager::getInstance();                                                          
    $manager->bindComponent('ChangeRequest', 'nosp');                                                    
    $manager->bindComponent('change_request', 'nosp');                                                   
class Addstatetochangerequest extends Doctrine_Migration_Base                                            
{                                                                                                        
  public function up()                                                                                   
  {                                                                                                      
    $this->addColumn('change_request', 'change_state', 'enum', array('values' => array('draft', 'submitted', 'approved', 'rejected', 'closed')));

This results in:

# ./symfony doctrine:migrate
>> doctrine  Migrating from version 0 to 1
                                                                                                                                                                                    
  The following errors occurred:                                                                                                                                                    
                                                                                                                                                                                    
   - SQLSTATE[42S02]: Base table or view not found: 1146 Table 'nosp_test_radius2.change_request' doesn't exist. Failing Query: "ALTER TABLE change_request ADD change_state TEXT"  

The database attempted to be used there is not the correct one.

Comment by Marcel Berteler [ 27/Sep/10 ]

second required patch to make Symfony work with 2 concurrent databases

Comment by Eugeniy Belyaev [ 21/Oct/10 ]
Another bad way to get it working in symfony:


ProjectConfiguration.class.php
  public function configureDoctrine(Doctrine_Manager $manager)
  {
    $files = sfFinder::type('file')
      ->maxdepth(0)
      ->not_name('*Table.class.php')
      ->name('*.class.php')
      ->in(sfConfig::get('sf_lib_dir') . '/model/doctrine');

    foreach ($files as $file) {
      $class_name = str_replace('.class.php', '', basename($file));
      Doctrine_Core::loadModel($class_name, $file);
    }
  }
Comment by Dean de Bree [ 16/Nov/10 ]

I found that if I changed the getTable function inside the Core.php file it seemed to work. Basically it forces the autoloader to load the object file, and when it does this it runs the bound connection statement to bind a table to a connection.

Core.php
/**
     * Get the Doctrine_Table object for the passed model
     *
     * @param string $componentName
     * @return Doctrine_Table
     */
    public static function getTable($componentName)
    {
        if (!class_exists($componentName)) {
            new $componentName();
        }

        return Doctrine_Manager::getInstance()->getConnectionForComponent($componentName)->getTable($componentName);
    }




[DC-717] Default value for columns is generated wrong. THe default value becomes the result value in the schema files. Created: 05/Jun/10  Updated: 06/Jun/10  Resolved: 06/Jun/10

Status: Resolved
Project: Doctrine 1
Component/s: Schema Files
Affects Version/s: 1.2.2
Fix Version/s: 1.2.2

Type: Bug Priority: Blocker
Reporter: angelo ayres camargo Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Apache 2.2, PostgresSQL 8.4, Windows XP



 Description   

When generating models from db with doctrine 1.2.2, default with functions in database get evaluated and the value goes to the generated schema files thus cousing error on insert/update.

Example:
Table:
CREATE TABLE Usuario (
id SERIAL NOT NULL,
apelido CHARACTER VARYING(50) NOT NULL,
email CHARACTER VARYING(255) NOT NULL,
dtRegistro TIMESTAMP DEFAULT 'now()' NOT NULL,
idUsuarioSituacao INTEGER,
senha CHARACTER(32),
CONSTRAINT PK_Usuario PRIMARY KEY (id),
CONSTRAINT TUC_Usuario_1 UNIQUE (email)
)

Code to generate files:
$dManager = Doctrine_Manager::getInstance();
$dManager->setAttribute(Doctrine::ATTR_MODEL_LOADING,Doctrine::MODEL_LOADING_CONSERVATIVE);
$dManager->setAttribute(Doctrine_Core::ATTR_MODEL_LOADING, Doctrine_Core::MODEL_LOADING_CONSERVATIVE);

$dManager->setAttribute(Doctrine::ATTR_PORTABILITY, Doctrine::PORTABILITY_NONE);
$dManager->setAttribute(Doctrine::ATTR_VALIDATE, Doctrine::VALIDATE_NONE);
$dManager->setAttribute(Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
$dManager->setAttribute(Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES, true);
$dManager->setAttribute(Doctrine::ATTR_QUERY_LIMIT, Doctrine::LIMIT_ROWS);

Doctrine_Core::generateModelsFromDb('c:\temp', array('dbcon'), array('generateTableClasses' => true, 'classPrefix' => 'D'));

Resulting file:
abstract class DBaseUsuario extends Doctrine_Record
{
public function setTableDefinition()

{ $this->setTableName('usuario'); $this->hasColumn('id', 'integer', 4, array( 'type' => 'integer', 'length' => 4, 'fixed' => false, 'unsigned' => false, 'primary' => true, 'sequence' => 'usuario_id', )); $this->hasColumn('apelido', 'string', null, array( 'type' => 'string', 'fixed' => false, 'unsigned' => false, 'notnull' => true, 'primary' => false, )); $this->hasColumn('email', 'string', null, array( 'type' => 'string', 'fixed' => false, 'unsigned' => false, 'notnull' => true, 'primary' => false, )); $this->hasColumn('dtregistro', 'timestamp', null, array( 'type' => 'timestamp', 'fixed' => false, 'unsigned' => false, 'notnull' => true, 'default' => '\'2010-06-04 11:10:12.078\'::timestamp without time zone', 'primary' => false, )); $this->hasColumn('idusuariosituacao', 'integer', 4, array( 'type' => 'integer', 'length' => 4, 'fixed' => false, 'unsigned' => false, 'notnull' => false, 'primary' => false, )); $this->hasColumn('senha', 'string', null, array( 'type' => 'string', 'fixed' => true, 'unsigned' => false, 'notnull' => false, 'primary' => false, )); }

}

The function now() for default value gets replaced by 'default' => '\'2010-06-04 11:10:12.078\'::timestamp without time zone',



 Comments   
Comment by angelo ayres camargo [ 06/Jun/10 ]

as of now i dont know if this is a error from case modeling tool or doctrine, will close and do further testing.





[DC-708] Wrong definition for MySQL string primary column Created: 28/May/10  Updated: 12/Jul/10

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

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

PHP 5.3.1, WinXP-SP3, Doctrine 1.2.2, MySQL 5.1.41


Attachments: File export_mysql_patch.diff    

 Description   

If you define a primary column, the attribute notnull is removed from the column definition because Doctrine assumes that primary columns are always not null.

Now suppose you have a schema like this, with a string primary column.

Client:
  columns:
    serial:    { type: string(50), notnull: true, primary: true }
    name:      { type: string(36), notnull: true }

That's fine, but causes problems with MySQL where the column is created with a default value of "" (empty string) and not <none>.

CREATE TABLE client (serial VARCHAR(50), name VARCHAR(36) NOT NULL, PRIMARY KEY(serial)) ENGINE = INNODB;

Note that the 2nd column is well defined and has <none> as default value (as seen from phpMyAdmin).

I attached a quick-workaround to disable the code which removes the notnull attribute from column definition.

After that the SQL code is like this:

CREATE TABLE client (serial VARCHAR(50) NOT NULL, name VARCHAR(36) NOT NULL, PRIMARY KEY(serial)) ENGINE = INNODB;


 Comments   
Comment by Claudio Nicora [ 28/May/10 ]

Attached a better patch where the notnull attribute is removed only if the primary column type is string

Comment by Claudio Nicora [ 28/May/10 ]

The same behaviour happens even for integer columns, so the notnull attribute should never be removed, not only for string columns. New patch attached, old one removed.

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

The patch I see currently just comments out the offending code. Is that intended? It cannot be committed if so

Comment by Claudio Nicora [ 08/Jun/10 ]

My patch only removed the effect, but it's not surely the best solution.

I've no sufficient knowledge on Doctrine to say that commenting out (or removing) that line will not affect other parts; that's why I only commented out the code instead of removing it (both on my side and on the attached patch).

If you think I'm not adding new bugs, I agree that removing the offending code is the cleanest way.

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

We can't just remove the code. It will change the behavior of the builder drastically which breaks backwards compatibility.

Comment by Claudio Nicora [ 08/Jun/10 ]

That's what I was afraid of.
Maybe you should change the code that generates the SQL for MySQL to make it include the "NOT NULL" clause to primary keys.

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

Hi, if you want to provide a patch that fixes your situation I can test it against our test suite and see if we can include it. You can also run your changes against the test suite to see if it causes any problems.

Comment by Claudio Nicora [ 13/Jun/10 ]

Hi, I attached a patch against Export/Mysql.php instead of the previous against Import/Builder.php.
It works on my side; can you please test it with your test suite?





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

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

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

Zend Framework, Ubuntu 9.10, MySQL



 Description   

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



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

Are you able to reproduce this in a test case?

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

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

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

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

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

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

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

Comment by Roland Huszti [ 06/Oct/10 ]

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

YAML

        date_of_birth:
            type: date

BASE MODEL

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

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

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

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

BASE MODEL

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

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

YAML

    fieldname:
         . . .
        notnull: false
        default: null

BASE MODEL

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

I hope it helps.





[DC-651] [PATCH] Doctrine_Record::option('orderBy', ...) of join's right side being applied to refTable in m2m relationship Created: 26/Apr/10  Updated: 31/Aug/11

Status: Open
Project: Doctrine 1
Component/s: Query, Relations
Affects Version/s: 1.2.2, 1.2.3
Fix Version/s: 1.2.2, 1.2.3, 1.2.4

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

CentOS 5.4
PHP 5.3.2
MySQL 5.1.44, for unknown-linux-gnu (x86_64)


Attachments: File DC651TestCase.php     File Query_orderBy_relation.diff     Text File Ticket_DC651.patch    

 Description   

When using the Doctrine_Record::option('orderBy', ...) feature on a table definition, where that table is the target of a many-to-many join, the specified orderBy columns are applied to the relation table's alias. So for example, given the following definitions:

class User extends Doctrine_Record {
  public function setTableDefinition() {
    $this->hasColumn('uid', 'integer', null, array('primary' => true));
    $this->option('orderBy', 'uid');
  }

  public function setUp() {
    $this->hasMany('Group as groups', array('refClass' => 'UserGroup', 'local' => 'user_uid', 'foreign' => 'group_id'));
  }
}

class Group extends Doctrine_Record {
  public function setTableDefinition() {
    $this->hasColumn('gid', 'integer', null, array('primary' => true));
  }

  public function setUp() {
    $this->hasMany('User as users', array('refClass' => 'UserGroup', 'local' => 'group_gid', 'foreign' => 'user_id'));
  }
}

class UserGroup extends Doctrine_Record {
  public function setTableDefinition() {
    $this->hasColumn('user_uid', 'integer', null, array('primary' => true));
    $this->hasColumn('group_gid', 'integer', null, array('primary' => true));
  }

  public function setUp() {
    $this->hasOne('User as user', array('local' => 'user_uid', 'foreign' => 'uid'));
    $this->hasOne('Group as group', array('local' => 'group_gid', 'foreign' => 'gid'));
  }
}

the following queries:

$query = Doctrine_Query::create()
  ->select('u.*')
  ->from('User u')
  ->leftJoin('u.groups g WITH g.gid=?', 1);
echo $query->getSqlQuery() . "\n";

$query = Doctrine_Query::create()
  ->select('g.*')
  ->from('Group g')
  ->leftJoin('g.users u WITH u.uid=?', 1);
echo $query->getSqlQuery() . "\n";

will output the following:

SELECT u.uid AS u__uid FROM user u LEFT JOIN user_group u2 ON (u.uid = u2.user_uid) LEFT JOIN group g ON g.gid = u2.group_id AND (g.gid = ?) ORDER BY u.uid
SELECT g.gid AS g__gid FROM group g LEFT JOIN user_group u2 ON (g.gid = u2.group_gid) LEFT JOIN user u ON u.uid = u2.user_id AND (u.uid = ?) ORDER BY u.uid, u2.uid

The orderBy option() call is applied to the User definition. The SQL for the first query is correct (where User is on the left side of the join). The SQL for the second query (where User is on the right-most side of the join), however, is obviously incorrect (UserGroup doesn't even have a uid column). Basically, User's orderBy option is being applied to both the User table and its respective reference table, UserGroup, when it is the target of a join.

After digging through the source for a while, I believe I've come up with a patch for this issue (which should be checked by someone more knowledgeable of Doctrine's internals). Basically, in the Doctrine_Query::buildSqlQuery() function, a call is made to Doctrine_Relation::getOrderByStatement() with the reference table (UserGroup)'s alias (u2), which in turn makes a call to Doctrine_Table::getOrderByStatement() on the referenced table (User), filling in the ORDER BY clause with User columns using UserGroup's alias. My solution was to reorder the logic so that the test for a reference class is made before the initial call to getOrderByStatement() is made. It seems to work against my test case and the test cases in the repository. I'll post my patch momentarily.

This bug was first mentioned in the comments in DC-313, but the original ticket comes across as more of a feature request for the hasMany() orderBy feature.



 Comments   
Comment by suhock [ 26/Apr/10 ]

attached a test case for this bug

Comment by suhock [ 26/Apr/10 ]

patch against /branches/1.2 HEAD (should also work apply to 1.2.2 tag)

Comment by Dan Ordille [ 30/Aug/10 ]

I can confirm this as an issue. However I don't think the above patch adequately fixes the problem it seems like with it an order by is still added for the ref column however the relation alias is lost.

My query with the patch became
SELECT g.gid AS g__gid FROM group g LEFT JOIN user_group u2 ON (g.gid = u2.group_gid) LEFT JOIN user u ON u.uid = u2.user_id AND (u.uid = ?) ORDER BY u.uid, uid

I made an another patch that prevents this extra order by clause from being added and have attached it.

Comment by suhock [ 21/Sep/10 ]

I tried out the new patch (Query_orderby_relation.diff), but it provides a reversed diff (patching goes from a patched version to the original). After applying it manually, it fails the provided test case and several additional test cases from the repository.

The original patch DOES pass the provided test case, when applied against 1.2.2, 1.2.3, or the 1.2 branch from the repository. It does not pass, however, Doctrine_Query_Orderby_TestCase. As the previous poster mentioned, it fails to resolve aliases in instances where the 'orderBy' option is specified in a relation definition.

I deleted the original patch and am providing a revised patch (Ticket_DC651.patch) against branch 1.2 HEAD (also works with 1.2.3), which fixes this issue. It passes all working test cases, including Doctrine_Query_Orderby_TestCase and DC651TestCase.

Comment by José De Araujo [ 31/Aug/11 ]

I had this issue recently on a application I'm working on as described the oderBy option was applied on the joined table on a column that even doesn't exist in it. I used the DC651 patch provided and it solved the issue, so far I haven't seen any side effect to it.





[DC-605] importSchema uses the connection name to identify the schema name Created: 28/Mar/10  Updated: 29/Mar/10  Resolved: 29/Mar/10

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

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

mysql5 unix



 Description   

importSchema in Doctrine_Import(l:369) iterates over the connections to check if it matches the passed $databases, however, giving the connection a name anything different than the databasename causes the entire function to malfunction..

So a workaround is to pass connection names as a second argument to `generateModelsFromDb` instead of the database names.

Also, if you wouldnt give a name to a connection, as you would possible do with cache connections since the argument isnt mandatory, then the equation is skipped entirely causing it to run on the cache connection..



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

Hi, the variable in the code is just not named very well. It is supposed to be connection names and not database names. I will rename the variable in the code.





[DC-602] Cardinality violation when searching phrase Created: 26/Mar/10  Updated: 29/Mar/10  Resolved: 29/Mar/10

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

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


 Description   

Im have setup search behaviour for my model.

Searching phrase "foo bar" throws "Doctrine_Connection_Mysql_Exception"

SQLSTATE[21000]: Cardinality violation: 1242 Subquery returns more than 1 row

To fix the issue replace line 208 in file: Doctrine/Search/Query.php

$where .= ' AND (position + ' . $k . ') = (SELECT position FROM ' . $this->_table->getTableName() . ' WHERE ' . $this->parseWord($word) . ')';

with:

$where .= ' AND (position + ' . $k . ') IN (SELECT position FROM ' . $this->_table->getTableName() . ' WHERE ' . $this->parseWord($word) . ')';






[DC-596] make it possible to pass in builderOptions for templates Created: 23/Mar/10  Updated: 29/Mar/10  Resolved: 29/Mar/10

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

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

Attachments: Text File Tag.php.patch     Text File Taggable.php.patch    

 Description   

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

It seems like it just requires to pass in a builderOption array into any class extending Doctrine_Record_Generator. I think it would be a good idea to start adding support for this into all internal behaviors.

and then doing something like the following in the schema:

Foo:
actAs:
Taggable:
builderOptions:
baseClassName: MyBaseRecord



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

You can go ahead and commit this. It looks good to me! Thanks, Jon

Comment by Lukas Kahwe [ 24/Mar/10 ]

ok .. i will apply the patch to the Taggable behavior. Not sure when I will find time to do the same for the core behaviors, a helping hand would be appreciated.

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

We can add it to the other behaviors as needed.





[DC-592] PHP Fatal error: Call to undefined method Doctrine_Connection_Oracle::getDeclaration() in ....\Doctrine\Export\Oracle.php on line 501 Created: 21/Mar/10  Updated: 29/Mar/10  Resolved: 29/Mar/10

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

Type: Bug Priority: Major
Reporter: zebulon303 Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 1
Labels: None


 Description   

When I try to execute a migration of my DB with doctrine CLI migrate, i get this error.
I fixed it changing the following in Export/Oracle.php
#501 : $fields[] = $this->conn->getDeclaration($fieldName, $field); => $fields[] = $this->getDeclaration($fieldName, $field);

#509 : $fields[] = $fieldName. ' ' . $this->conn->getDeclaration('', $field['definition']); => $fields[] = $fieldName. ' ' . $this->getDeclaration('', $field['definition']);






[DC-579] Doctrine_Record->_get() with $load === false generates E_NOTICE (patch) Created: 17/Mar/10  Updated: 29/Mar/10  Resolved: 29/Mar/10

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

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

Attachments: Text File Record.php.patch    

 Description   

In Record.php, _get() method called with $load parameter setted to false can generate an E_NOTICE.
Attached patch fix this.



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

Thanks for the issue and patch.





[DC-577] Sluggable can not index slug if using a provider Created: 16/Mar/10  Updated: 16/Mar/10  Resolved: 16/Mar/10

Status: Resolved
Project: Doctrine 1
Component/s: Sluggable
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

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

Attachments: Text File Sluggable.patch    

 Description   

The Sluggable template does not add an index for the slug if the fields option is empty.

The provider option will not be used if the fields option is not empty.

The Sluggable template does not use the fields option in creating the index for the slug, so removing the requirement for a non-empty fields option seems to be an appropriate fix.






[DC-574] Add support for __toString() in the generator Created: 15/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Attachments: Text File Builder.php.patch     Text File Generator.php.patch    

 Description   

I noticed that the TaggableTag class does not contain a __toString() method. Looking further I found that the generator does not support this atm, but it was easy to add.






[DC-573] Invalid SQL generated by Doctrine_Query::getLimitSubquery() when ordering by multiple columns Created: 15/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

PHP 5.3
Windows XP
MSSQL Server 2008


Attachments: Text File doctrine_query_patch.patch     File index.php     File Query.php    

 Description   

When attempting to order a query by multiple columns I came across this bug. I've attached a reproduction script which will hopefully illustrate the behaviour, but essentially getLimitSubquery() is parsing the order by column incorrectly, leading to an erroneous comma in the sub-select field select clause, e.g

SELECT [m].[id] AS [m__id], [m].[name] AS [m__name], [m].[date] AS [m__date], [r].[id] AS [r__id], [r].[model_id] AS [r__model_id], [r].[name] AS [r__name] FROM [model] [m] INNER JOIN [relation] [r] ON [m].[id] = [r].[model_id] WHERE [m].[id] IN (SELECT TOP 1 [inner_tbl].[id] FROM (SELECT DISTINCT TOP 1 [m].[id], [r].[name],, [r].[id] FROM [model] [m] INNER JOIN [relation] [r] ON [m].[id] = [r].[model_id] ORDER BY [r].[name], [r].[id]) AS [inner_tbl] ORDER BY [inner_tbl].[name] DESC, [inner_tbl].[id] DESC) ORDER BY [r].[name], [r].[id]

(note [r].[name],, [r].[id] - that's the offender).

I've attached a patch against 1.2 HEAD that strips any commas from the fields before they are added to the select clause; it works for me but I'm not sure of all the use cases across the relevant drivers.



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

I don't see any patch attached to the ticket. If you can provide more information and a diff/patch we can consider it for the next release. Thanks, Jon

Comment by Craig Marvelley [ 15/Mar/10 ]

Sigh. Sorry, attached the file instead of the patch.

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

Thanks for the issue and patch





[DC-570] Make table classes suffix configurable (with patch) Created: 13/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Attributes, Import/Export
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

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

Attachments: File patch-doctrine-table-class-suffix.diff    

 Description   

I follow Zend Framework (PEAR) class naming conventions, and my user table class should be named User_Table instead of UserTable and be placed in User/Table.php instead of UserTable.php. Since Table suffix is hardcoded, it's not possible to do that.

I added ATTR_TABLE_CLASS_SUFFIX attribute and set it to Table by default, so that existing code is not affected. Now, if I want, I can change that prefix to _Table and be happy. The patch is attached.



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

I like the idea, but the patch is not quite right. We should not use an attribute for this, it should just be an option in the builder. I committed a fix for this and should solve your problem.

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

Just a note, my previous comment is wrong. We do need this to be an attribute so that the Connection.php can load the tables too with the right format.





[DC-569] Duplicate unique indexes on PostgreSQL Created: 13/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Cli, Native SQL
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

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

Window, Ubuntu, PostgreSQL 8.3, PHP 5.3


Attachments: File schema.yml    

 Description   

Generated by doctrine-cli SQL is:

– this is ok
CREATE TABLE "image" ("id" BIGSERIAL, "alt" VARCHAR(255), "title" VARCHAR(500), "filename" VARCHAR(255), "width" BIGINT, "height" BIGINT, "slug" VARCHAR(255), "createdat" TIMESTAMP NOT NULL, "updatedat" TIMESTAMP NOT NULL, PRIMARY KEY("id"));
CREATE TABLE "news" ("id" BIGSERIAL, "title" VARCHAR(255), "leadmarkup" VARCHAR(500), "leadhtml" VARCHAR(600), "bodymarkup" TEXT, "bodyhtml" TEXT, "slug" VARCHAR(255), "createdat" TIMESTAMP NOT NULL, "updatedat" TIMESTAMP NOT NULL, PRIMARY KEY("id"));
CREATE TABLE "snippet" ("id" BIGSERIAL, "name" VARCHAR(255), "bodymarkup" TEXT, "bodyhtml" TEXT, "slug" VARCHAR(255), "createdat" TIMESTAMP NOT NULL, "updatedat" TIMESTAMP NOT NULL, PRIMARY KEY("id"));
– this causes error
CREATE UNIQUE INDEX "sluggable" ON "image" ("slug");
CREATE UNIQUE INDEX "sluggable" ON "news" ("slug");
CREATE UNIQUE INDEX "sluggable" ON "snippet" ("slug");

After importing this to PostgreSQL, I get 'index already exists' error.

On PostgreSQL unique indexes names must not be the same.
I think the correct form should be:
CREATE UNIQUE INDEX "sluggable-image" ON "image" ("slug");
CREATE UNIQUE INDEX "sluggable-news" ON "news" ("slug");
CREATE UNIQUE INDEX "sluggable-snippet" ON "snippet" ("slug");

Schema file attached.



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

This was fixed here http://trac.doctrine-project.org/changeset/7372





[DC-568] Make it possible to use microtime as the version value when using Versionable Created: 13/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Attachments: Text File Listener.php.patch     File Microtime.php     Text File Versionable.php.patch    

 Description   

This patch basically makes it possible to pass in a custom auditlog listener as well as providing a new listener that uses microtime to generate the version value's instead of incrementing an integer value starting at 1. This should provide a much better handling for concurrent inserts and should also be faster, since for all but the first version a complex select is necessary in the current implementation.

Open question is if the accuracy multiplier should be an option or not. Also is there any reason why the column definition doesnt default to an unsigned, not that it matters all that much?



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

Thanks to Lukas this is fixed now.





[DC-567] RawSql: getCountSqlQuery does not work correctly with PostgreSQL (patch provided) Created: 12/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Bug Priority: Major
Reporter: Raphaël Dehousse Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

Dears,

Line 309 in Doctrine_RawSql:

        $q = 'SELECT COUNT( DISTINCT '.implode(',',$fields).') as num_results';

        $string = $this->getInheritanceCondition($this->getRootAlias());
        if ( ! empty($string)) {
            $this->_sqlParts['where'][] = $string;
        }

        $q .= ( ! empty($this->_sqlParts['from']))?    ' FROM '     . implode(' ', $this->_sqlParts['from']) : '';
        $q .= ( ! empty($this->_sqlParts['where']))?   ' WHERE '    . implode(' AND ', $this->_sqlParts['where']) : '';
        $q .= ( ! empty($this->_sqlParts['groupby']))? ' GROUP BY ' . implode(', ', $this->_sqlParts['groupby']) : '';
        $q .= ( ! empty($this->_sqlParts['having']))?  ' HAVING '   . implode(' AND ', $this->_sqlParts['having']) : '';

produces with PostgreSQL: Undefined function: 7 ERROR: function count(bigint, integer) does not exist

but

        $q = 'SELECT COUNT(*) as num_results FROM (SELECT DISTINCT '.implode(', ',$fields);

        $string = $this->getInheritanceCondition($this->getRootAlias());
        if ( ! empty($string)) {
            $this->_sqlParts['where'][] = $string;
        }

        $q .= ( ! empty($this->_sqlParts['from']))?    ' FROM '     . implode(' ', $this->_sqlParts['from']) : '';
        $q .= ( ! empty($this->_sqlParts['where']))?   ' WHERE '    . implode(' AND ', $this->_sqlParts['where']) : '';
        $q .= ( ! empty($this->_sqlParts['groupby']))? ' GROUP BY ' . implode(', ', $this->_sqlParts['groupby']) : '';
        $q .= ( ! empty($this->_sqlParts['having']))?  ' HAVING '   . implode(' AND ', $this->_sqlParts['having']) : '';

        $q .= ') as results';

works and should work with every database server.

Continue your great work

Regards,

Raphaël Dehousse



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

Hi, it would be really helpful if all suggested changes are supplied as a patch.





[DC-565] Versionable bugging when used with I18N Created: 12/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Attachments: File audit_log.diff    

 Description   

The solution was to allow Versionable to skip fields.
I've fixed with this changing:

Doctrine/AuditLog.php
#84:

$skipFields = (isset($this->_options['skipFields']))?$this->_options['skipFields']:array();

#88:

//inside the foreach
if(in_array($column, $skipFields))

Unknown macro: { continue; }

After that the Versionable will accept some parameters.

ps: If possible, let me know about this changes cause my sources are with this fix.






[DC-564] Postgresql: listSequences: relname badly "formatted" (patch provided) Created: 11/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

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

Attachments: Text File DC-564_Doctrine_Import_Pgsql.php.patch    

 Description   

Dears,

Let's say you create your database first. If you have a serial/bigserial, a sequence is automaticaly created. It's called for example: 'id_seq'
During the cretion of the model, the sequence name is, so, called id_seq.

But in Doctrine_Formatter, line 233, you have getSequenceName that format Doctrine_Core::ATTR_SEQNAME_FORMAT that comes from Doctrine_Manager line 143, you have Doctrine_Core::ATTR_SEQNAME_FORMAT => "%s_seq", so, the sequence name will wrongly be id_seq_seq.

This could be avoid if the sequence_name would not contain the "_seq" suffix coming from the import. WDYT?

This could be possible thanks to a change in Doctrine_Import_Pgsql, line 50:

'listSequences' => "SELECT
        rtrim(relname, '_seq')
    FROM
        pg_class
    WHERE relkind = 'S' AND relnamespace IN
        (SELECT oid FROM pg_namespace
        WHERE nspname NOT LIKE 'pg_%' AND nspname != 'information_schema')",

So, rtrim(relname, '_seq') in place of relname only.
I'm not sure rtrim is the best solution but you got what I meant.

Voilà my 2 cents.

Hope it will help

Best regards,

Raphaël Dehousse



 Comments   
Comment by Raphaël Dehousse [ 15/Mar/10 ]

Here is a patch to apply in the doctrine lib directory





[DC-563] Import/Pgsql: listTableRelations: bad use of strpos search composite foreign keys (patch provided) Created: 11/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

Type: Bug Priority: Major
Reporter: Raphaël Dehousse Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: Text File DC-563_Doctrine_Import_Pgsql.php.patch    

 Description   

Dears,

First, I would like to thank you for your great work.

Second, the bug:

Line ~279 in the function listTableRelations, there is a mistake in the use of strpos : strpos(',', $values[1]) and strpos(',', $values[3]), it should be strpos($values[1], ',') and strpos($values[2], ',')

With this code, strpos always returns false and so, the composite foreign keys are not skipped as desired.

Continue your great job

Regards,

Raphaël Dehousse



 Comments   
Comment by Raphaël Dehousse [ 15/Mar/10 ]

The fix you did does not fix the problem

The problem is the order of the parameter in strpos

I will create a patch this avond and attach it here

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

I see, that is why patches are always preferred. it is impossible to copy and paste changes out of a comment Patches should always be attached!

Comment by Raphaël Dehousse [ 15/Mar/10 ]

Here is a patch.

You can apply it on the last revision of the branch 1.2

The patch is to apply on the file Doctrine/Import/Pgsql.php

Comment by Raphaël Dehousse [ 15/Mar/10 ]

Here is the patch as promised

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

Thanks for the patch





[DC-561] Doctrine autoloader tries to load class again and fails with fatal error - with fix Created: 10/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Bug Priority: Blocker
Reporter: Miha Vrhovnik Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

Doctrine_Core::autoload around line 1107
if (strpos($className, 'sfYaml') === 0 || class_exists($className, false)) {

should be changed to

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

otherwise you get:
Warning: require(/srv/www/pacs.lan/site/lib/Doctrine/Parser/sfYaml/Doctrine_Query_From.php) [function.require]: failed to open stream: No such file or directory in /srv/www/pacs.lan/site/lib/Doctrine/Core.php on line 1108

Fatal error: require() [function.require]: Failed opening required '/srv/www/pacs.lan/site/lib/Doctrine/Parser/sfYaml/Doctrine_Query_From.php' (include_path='/srv/www/pacs.lan/site/lib/:/srv/www/pacs.lan/site/lib/Dwoo/:.:/usr/local/lib/php') in /srv/www/pacs.lan/site/lib/Doctrine/Core.php on line 1108



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

It appears this is already fixed in the latest SVN of 1.2.





[DC-559] Doctrine_Core::loadModels() caching Created: 09/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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


 Description   

Add ability to cache result of Doctrine_Core::loadModels().
My "models" folder contains more than 20 record classes plus more than 20 base classes. I added result caching for conservative model loading and it's reduced application bootstrap time more than 100ms.
Here code that I added to Doctrine_Core::loadModels()
Cache hit check at the beginning of the method

                $models = zend_shm_cache_fetch('doctrine::models_conservative');
                $modelPatch = zend_shm_cache_fetch('doctrine::models_conservative_paths');
                if(false !== $models && false !== $modelPatch){
                    self::$_loadedModelFiles = $modelPatch;
                    return $models;
                }

Result caching before return data

           asort($loadedModels);
            zend_shm_cache_store('doctrine::models_conservative',$loadedModels);
            zend_shm_cache_store('doctrine::models_conservative_paths',self::$_loadedModelFiles);
            return $loadedModels;

Of course zend_shm_cache_* is not proposed as caching solution.
I didn't use agressive model loading, but I think that caching for aggresive modlel loading can be done with compilation of all models to one file



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

The changes are not valid and you can do the same thing outside of Doctrine in your bootstrap. We don't need to patch Doctrine in order for you to do this.





[DC-557] Primary Key Error Created: 09/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Bug Priority: Major
Reporter: Sid GBF Assignee: Jonathan H. Wage
Resolution: Incomplete Votes: 0
Labels: None


 Description   

All keys are being set as primary key, wich is useless once we have a serial.

Fix: Doctrine/I18n.php
#098: $defaultOptions = array(
#099: 'fixed' => true,
#100: 'primary' => false
#101: )



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

These changes are not valid and they break the test case. Not enough information is present for this to be valid or a complete ticket. Please re-open if you have more information or a proper patch.





[DC-556] Index name error Created: 09/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Attachments: File sluggable.diff    

 Description   

At this moment, if you have more than one table that is sluggable, it get an error cause tries to set the very same name to ALL sluggable indexes. Here is a fix:

#55: 'indexName' => null

#74: if($this->_options['indexName'] === null)
#75: $this->_options['indexName'] = $this->getTable()- >getTableName().'_sluggable';



 Comments   
Comment by Sid GBF [ 15/Mar/10 ]

Fixing some typos

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

Thanks for the issue and patch.





[DC-555] infinite recursion happens when saving models with circular reference Created: 09/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

linux, symfony 1.4


Attachments: File UnitOfWork.php    

 Description   

After upgrading symfony from 1.2 to 1.4, my website began to have problems saving some models. After some research, I found that it was caused by infinite recursion. Let's say Model A has many B (B belongs to A). Each A also points to one of the B objects it owns. So it's a circular reference. Some ppl might argue that it's not a good pratice to have circular reference in the data model, I agree. But it worked fine in Doctrine 1.0, so I prefer not to change it. In Doctrine 1.2.1, it seems that when A and its related B are both modified (dirty), if I try to save A, Doctrine will try to save B due to cascade update, and when saving B, it will again try to save its related A ...

I compared the source code of Doctrine_Connection_UnitOfWork between 1.0 and 1.2.1, and found out that in Doctrine 1.2.1, the model is no longer locked when saveRelatedLocalKeys is invoked. I don't understand this change. After I changed the line "$this->saveRelatedLocalKeys($record);" to

$record->state($record->exists() ? Doctrine_Record::STATE_LOCKED : Doctrine_Record::STATE_TLOCKED);
$this->saveRelatedLocalKeys($record);
$record->state($state);

my website returned to normal again. And so far i haven't found any problem caused by my change

So I hope someone can look into this and let me know if my change is safe. Or if I'm wrong, is there any way I can get around the infinite recursion problem without changing my database schema? Thanks.



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

Thanks for the issue and patch!





[DC-550] Cannot update record from one large integer to another large integer (severe problem for 32bit systems, due to the low upper limit of the int data type) Created: 07/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Symfony 1.4 from http://svn.symfony-project.com/branches/1.4, Windows XP Pro SP2, 32bit Processor, PHP 5.2.8, MySQL


Attachments: Text File Record.php.patch     Text File Record.php.patch    

 Description   

From what I understand, doctrine mostly stores integers as strings. To check whether an integer has been modified, the following code in Doctrine_Record is used:

    protected function _isValueModified($type, $old, $new)
    {
        if ($new instanceof Doctrine_Expression) {
            return true;
        }

        if ($type == 'boolean' && (is_bool($old) || is_numeric($old)) && (is_bool($new) || is_numeric($new)) && $old == $new) {
            return false;
        } else if (in_array($type, array('decimal', 'float')) && is_numeric($old) && is_numeric($new)) {
            return $old * 100 != $new * 100;
        } else if (in_array($type, array('integer', 'int')) && is_numeric($old) && is_numeric($new)) {
            return (int) $old !== (int) $new;  # <--- ********** THIS LINE CASTS STRING TO INT **********
        } else if ($type == 'timestamp' || $type == 'date') {
            return strtotime($old) !== strtotime($new);
        } else {
            return $old !== $new;
        }
    }

On the line indicated above an integer, stored as a string, is cast to a PHP integer data type, and compared with the existing value of the field currently stored in the database. For values that fall within the int type range, this works fine. However, when changing a value falling above the range, which on 32bit systems is 2147483647, to another value falling above the range, these casts cause the code to evaluate both as 2147483647 and hence the field is not added to the _IsModified() array, and the value is not updated.

Bearing in mind that validation to confirm whether these strings are in numeric format should already have occurred by this point in the process, is there any need to cast the strings at all? Thus, is the following a possible solution?

            return $old !== $new;

This seems to work fine for me in my limited trials although, admittedly, there may be some consequences about which I am not aware.

Note that this issue is not so evident on 64bit systems, where the upper limit is much higher.



 Comments   
Comment by hal [ 09/Mar/10 ]

Patch for described problem (untested)





[DC-549] Doctrine_DataDict_Oracle TYPO Created: 07/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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


 Description   

grep -rn 'lenght' Doctrine/*
Doctrine/DataDict/Oracle.php:197: $lenght = 3;

MEDIUMINT error

} elseif ( ! is_null($length) && (int)$length <= 3) { // TINYINT
    $length = 1;
} elseif ( ! is_null($length) && (int)$length <= 5) { // SMALLINT
    $length = 2;
} elseif ( ! is_null($length) && (int)$length <= 8) { // MEDIUMINT
    $lenght = 3;
} elseif ( ! is_null($length) && (int)$length <= 10) { // INT
    $length = 4;
} elseif ( ! is_null($length) && (int)$length <= 20) { //BIGINT
    $length = 8;
}


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

Thanks for the issue and patch. For future reference, it is easier if you provide a patch produced by svn. Thanks again, Jon!





[DC-546] [PATCH] Missing $this->_table in Doctrine_Search when Index table not generated on the fly, throws Doctrine_Search_Exception' with message 'Invalid argument type. Expected instance of Doctrine_Table Created: 04/Mar/10  Updated: 11/Mar/10  Resolved: 11/Mar/10

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

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

Attachments: File doctrine_1.2.1_searchable_generated_class_serach_missing_table    

 Description   

See http://trac.doctrine-project.org/ticket/896.
Its closed as invalid, but 1.2.1 (stable) throws 'Doctrine_Search_Exception' with message 'Invalid argument type. Expected instance of Doctrine_Table.' if the searchable behavior's index table is not generated on-the-fly, because Doctrine_Search::buildTable() never gets invoked.

It's possible to workaround it by deleting generated classes.

Patch attached.






[DC-545] MSSQL Server: Inserting blank records throws exception / Invalid casting of bound query parameters in sub-selects. Created: 04/Mar/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

PHP 5.3.1
Windows XP
Microsoft SQL Server 2008


Attachments: Text File Doctrine_Connection_MSSQL.patch    

 Description   

I've two issues with saving records with SQL Server.

Firstly, SQL Server does not allow NULL or DEFAULT values to be used against identity columns. When inserting a record without any modified fields, Doctrine_Record_UnitOfWork::processSingleInsert sets all fields to NULL - including the identity columns. This causes this error:

"SQLSTATE[42000]: Syntax error or access violation: 339 [Microsoft][SQL Server Native Client 10.0][SQL Server]DEFAULT or NULL are not allowed as explicit identity values"

Ideally identity columns could be excluded but that would break tables that consist of those columns. Instead I've patched Doctrine_Connnection_MSSQL to, in this 'blank insert' circumstance only, insert default values and then update the inserted row with null values as necessary (the latter may be unnecessary but I wanted to preserve the original behaviour).

Secondly, there exists a bug in (as I understand it) Microsoft's ODBC driver [1], that causes all bound parameters within a sub-select to be cast as strings before being interpreted by SQL Server. This results in the following error:

SQLSTATE[22018]: Invalid character value for cast specification: 206

[1] http://bugs.php.net/36561

When using SQL Server through ODBC all Doctrine queries that use sub-selects are failing, for example the query generated by a Doctrine_Table->find()

SELECT * FROM (SELECT TOP 1 * FROM (SELECT TOP 1 [m].[id] AS [m__id], [m].[name] AS [m__name] FROM [model] [m] WHERE ([m].[id] = ?)) AS [inner_tbl]) AS [outer_tbl]

To combat this I've extended the Doctrine_Connection_Common execute() method in Doctrine_Connection_Mssql to replace bound parameters so they're inline instead. This has its drawbacks, like reduced protection against SQL injection, but since the alternative is the majority of my queries failing I don't see a better option.

I realise this second issue isn't a Doctrine concern per se, but I thought I'd bring it up since I imagine anyone using SQL server will be experiencing it.

A patch against 1.2.1 is attached. This patch also incorporates the latest patch in http://www.doctrine-project.org/jira/browse/DC-289, which has now been committed to trunk; my additions are at the bottom of the file.



 Comments   
Comment by Craig Marvelley [ 05/Mar/10 ]

Updated original ticket as another issue I found is closely linked and involved refactoring of my original patch.

Comment by Craig Marvelley [ 05/Mar/10 ]

Updated patch

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

Hi, I tried applying your patch to Doctrine 1.2 latest SVN to give it a test and it did not apply cleanly. Please re-open if you can provide an updated patch.

Thanks, Jon

Comment by Craig Marvelley [ 11/Mar/10 ]

Updated patch that should apply cleanly.

Comment by Craig Marvelley [ 11/Mar/10 ]

Hi, thanks for looking at this. I've updated the patch against 1.2 HEAD, hopefully that'll apply for you.





[DC-543] Doctrine_Inflector::unaccent does not replace the norwegian characters æøå Created: 03/Mar/10  Updated: 16/Mar/10  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Sluggable
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
Fix Version/s: 1.2.2

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

all


Attachments: Text File inflector.patch    

 Description   

Doctrine_Inflector::unaccent does not know about the norwegian accent characters æøåÆØÅ so when sluggable is making slugs it ends up splitting words

"Møte" is turned into 'm-te' instead of 'mote' which is more apropriate



 Comments   
Comment by Ivar Nesje [ 04/Mar/10 ]

Sory, the patch had a little typo. I forgot to add a , after the previously last entry in the array.





[DC-537] Timestamp Validator splits on wrong character (from Trac #2018) Created: 02/Mar/10  Updated: 24/Jun/10  Resolved: 15/Mar/10

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

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

Problem exists in SVN as of r7298


Attachments: Text File Doctrine_TimestampValidation.patch    

 Description   

To validate data of type 'timestamp', the validator splits the Date/Time using a space, where as, the format created by date('c') specifies a 'T' to split the Date/Time. It seems the simple fix should be to change the space on line 47 of Doctrine/Validator/Timestamp.php to a 'T'

Date generated from gmdate('c') - 2010-03-02T22:08:56+00:00



 Comments   
Comment by Dave Rowe [ 02/Mar/10 ]

Patch to explode on 'T' instead of ' ', to align with the expected results of gmdate('r')

Comment by Steffen Zeidler [ 24/Jun/10 ]

So how do I now validate datetime values (YYYY-MM-DD HH-MM-SS) before that bugfix? I'm using mysql 5.0, that uses YYYY-MM-DD for column type datetime. May be there should be another validator for that format, thats splits by a space.





[DC-529] HYDRATE_SINGLE_SCALAR returns false for fetchOne() correct value for execute() Created: 26/Feb/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

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

Linux 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:02:26 UTC 2010 x86_64 GNU/Linux
mysql Ver 14.14 Distrib 5.1.37, for debian-linux-gnu (x86_64) using EditLine wrapper
Apache/2.2.12 (Ubuntu)
PHP 5.3.1
Doctine 1.2 rev 7229



 Description   

This simple query:

$vRetVal = Doctrine_Query::create()
->select('id')
->from('LocationCombined')
->where('name = ?', $pRegionName)
->fetchOne(array(), Doctrine_Core::HYDRATE_SINGLE_SCALAR);

returns "false", but if I use
->execute(array(), Doctrine_Core::HYDRATE_SINGLE_SCALAR);

I get the correct result in my variable.






[DC-524] Out Of Range in Template Geographical Calculation using Postgresql Created: 25/Feb/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Geographical
Affects Version/s: 1.2.0
Fix Version/s: 1.2.2

Type: Bug Priority: Critical
Reporter: Nei Rauni Santos Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

PostgreSQL 8.3 on Linux


Attachments: Text File Geographical.patch    

 Description   

500 | Internal Server Error | Doctrine_Connection_Pgsql_Exception
SQLSTATE[22003]: Numeric value out of range: 7 ERROR: input is out of range

DQL:

at Doctrine_Connection->execute('SELECT h.id AS h_id, h.name AS hname, h.address AS haddress, h.zip AS hzip, h.url AS hurl, h.photo_url AS hphoto_url, h.checkin_from AS hcheckin_from, h.checkin_to AS hcheckin_to, h.checkout_from AS hcheckout_from, h.checkout_to AS hcheckout_to, h.is_published AS his_published, h.class AS hclass, h.currencycode AS hcurrencycode, h.minrate AS hminrate, h.maxrate AS hmaxrate, h.preferred AS hpreferred, h.nr_rooms AS hnr_rooms, h.bookable_direct AS hbookable_direct, h.ranking AS hranking, h.city_id AS hcity_id, h.policygroup_id AS hpolicygroup_id, h.is_closed AS his_closed, h.hoteltype_id AS hhoteltype_id, h.class_is_estimated AS hclass_is_estimated, h.review_nr AS hreview_nr, h.review_score AS hreview_score, h.created_at AS hcreated_at, h.updated_at AS hupdated_at, h.latitude AS hlatitude, h.longitude AS hlongitude, ((ACOS(SIN(45.41244780000000000000 * PI() / 180) * SIN(h.latitude * PI() / 180) + COS(45.41244780000000000000 * PI() / 180) * COS(h.latitude * PI() / 180) * COS((6.63685100000000000000 - h.longitude) * PI() / 180)) * 180 / PI()) * 60 * 1.1515) AS h0, ((ACOS(SIN(45.41244780000000000000 * PI() / 180) * SIN(h.latitude * PI() / 180) + COS(45.41244780000000000000 * PI() / 180) * COS(h.latitude * PI() / 180) * COS((6.63685100000000000000 - h.longitude) * PI() / 180)) * 180 / PI()) * 60 * 1.1515 * 1.609344) AS h1 FROM hotel h WHERE (((ACOS(SIN(45.41244780000000000000 * PI() / 180) * SIN(h.latitude * PI() / 180) + COS(45.41244780000000000000 * PI() / 180) * COS(h.latitude * PI() / 180) * COS((6.63685100000000000000 - h.longitude) * PI() / 180)) * 180 / PI()) * 60 * 1.1515 * 1.609344) < 3 AND h.is_published = ? AND h.id != ?) ORDER BY h_1 asc LIMIT 5', array('true', 189646))

in SF_SYMFONY_LIB_DIR/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Query/Abstract.php line 976

I'm using NUMERIC on column type with precision 10, but the problem is not in the column latitude and longitude, it´s on calculation.
To resolve this bug I made a casting inside of ACOS function calculation, but I don't know how it work on mysql.

      • I've posted a patch file attached here with the change that I made.

Examples of result of h_0, h_1 on sql fixed.

0.132901717706014221300; 0.213884392376139928479590400
0.15938002241913817800; 0.256497124695862251207283200
0.205676327970298764600; 0.331003964361032495016422400
0.205676327970298764600; 0.331003964361032495016422400






[DC-522] Can not use charset and collate in a table basis when using global charset and collate in Doctrine_Manager Created: 24/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Wamp 2.0, Windows XP PS2.


Attachments: Text File Doctrine_Table___construct.txt    

 Description   

Can not use charset and collate in a table basis when using global charset and collate in Doctrine_Manager.

When using + symfony:

ProjectConfiguration.class.php
public function configureDoctrine(Doctrine_Manager $manager)
  {
    $manager->setCharset('utf8');
    $manager->setCollate('utf8_bin');
  }

And some schema like,

schema-page.yml

PageIndex:
  tableName:                           t_page_index
  columns:
    id:                                { type: integer  , length: 20 , primary: true    , autoincrement: true                                                  }
    title:                             { type: string   , length: 200                   , notnull: true                                                        }
  options:
    collate:                           utf8_general_ci
    

When generating the database, the table will have as collate utf8_bin, not being possible overwriting it at a table level.

This is because:

Table.class.php
public function __construct($name, Doctrine_Connection $conn, $initDefinition = false)
    {
        $this->_conn = $conn;
        $this->_options['name'] = $name;
        
        $this->setParent($this->_conn);           
        $this->_conn->addTable($this);
        
        $this->_parser = new Doctrine_Relation_Parser($this);
        
        if ($initDefinition) {
            $this->record = $this->initDefinition();

            $this->initIdentifier();

            $this->record->setUp();

            // if tree, set up tree
            if ($this->isTree()) {
                $this->getTree()->setUp();
            }
        } else {
            if ( ! isset($this->_options['tableName'])) {
                $this->setTableName(Doctrine_Inflector::tableize($this->_options['name']));
            }
        }
        
        $this->_filters[]  = new Doctrine_Record_Filter_Standard();
        $this->_repository = new Doctrine_Table_Repository($this);

        if ($charset = $this->getAttribute(Doctrine_Core::ATTR_DEFAULT_TABLE_CHARSET)) {
            $this->_options['charset'] = $charset;
        }
        if ($collate = $this->getAttribute(Doctrine_Core::ATTR_DEFAULT_TABLE_COLLATE)) {
            $this->_options['collate'] = $collate;
        }

        $this->construct();
    }

Here the charset and the collate are overwritten (in the last lines of the method) by the global values.

A fix could be something like:

Table.class.php
public function __construct($name, Doctrine_Connection $conn, $initDefinition = false)
    {
        $this->_conn = $conn;
        $this->_options['name'] = $name;
        
        $this->setParent($this->_conn);           
        $this->_conn->addTable($this);
        
        $this->_parser = new Doctrine_Relation_Parser($this);
        

        if ($charset = $this->getAttribute(Doctrine_Core::ATTR_DEFAULT_TABLE_CHARSET)) {
            $this->_options['charset'] = $charset;
        }
        if ($collate = $this->getAttribute(Doctrine_Core::ATTR_DEFAULT_TABLE_COLLATE)) {
            $this->_options['collate'] = $collate;
        }

        if ($initDefinition) {
            $this->record = $this->initDefinition();

            $this->initIdentifier();

            $this->record->setUp();

            // if tree, set up tree
            if ($this->isTree()) {
                $this->getTree()->setUp();
            }
        } else {
            if ( ! isset($this->_options['tableName'])) {
                $this->setTableName(Doctrine_Inflector::tableize($this->_options['name']));
            }
        }
        
        $this->_filters[]  = new Doctrine_Record_Filter_Standard();
        $this->_repository = new Doctrine_Table_Repository($this);

        

        $this->construct();
    }

Now the initDefinition method is called after the setup of the global charset and collate. Then if found a collate option in the table then that collate will be used.



 Comments   
Comment by Jonathan H. Wage [ 02/Mar/10 ]

Can you provide your changes as a patch?

Comment by Jonathan Nieto [ 09/Mar/10 ]

Patch done!.

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

Thanks again for another issue and patch





[DC-521] Empty records cannot be inserted on PostgreSQL with autoincrement identifiers Created: 23/Feb/10  Updated: 17/Jun/10  Resolved: 01/Mar/10

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

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

Ubuntu 9.10
PostgreSQL 8.4
PHP 5.2.10-2ubuntu6.4
Doctrine 1.2 stable branch (r7206)


Attachments: Text File doctrine-1.2-emptyinsert.patch    

 Description   

If a record does not have any values set, but its identifier is defined as autoincrement, the record cannot be inserted into PostgreSQL.

In Doctrine_Connection_UnitOfWork::processSingleInsert():

 
       $fields = $record->getPrepared();
        $table = $record->getTable();

       // Populate fields with a blank array so that a blank records can be inserted
        if (empty($fields)) {
            foreach ($table->getFieldNames() as $field) {
                $fields[$field] = null;
            }
        }

This code snippet will add null values to all fields, including to the autoincrement identifier.
Then later in Doctrine_Connection_Pgsql::insert():

       // fix #1786 and #2327 (default values when table is just 'id' as PK)
        if(count($fields) === 1 && $table->isIdentifier(key($fields)) && $table->isIdentifierAutoincrement() )
        {
            return $this->exec('INSERT INTO ' . $this->quoteIdentifier($tableName)
                              . ' '
                              . ' VALUES (DEFAULT)');
        }

        foreach ($fields as $fieldName => $value) {
            $cols[] = $this->quoteIdentifier($table->getColumnName($fieldName));
            if ($value instanceof Doctrine_Expression) {
                $a[] = $value->getSql();
                unset($fields[$fieldName]);
            } else {
                $a[] = '?';
            }
        }

The claimed fix for the referenced tickets does not work correctly for 2 reasons:
1. It only works for tables with a single id field
2. It only works correctly if the id field had no value assigned. If there was a value assigned, it silently bypasses it, and inserts with the autoincremented value.

Patch with test case will be attached to the ticket.

References:
http://trac.doctrine-project.org/ticket/2327
http://trac.doctrine-project.org/ticket/1786



 Comments   
Comment by Gergely Kis [ 23/Feb/10 ]

The patch contains:

  • Fix for the empty insert issue in PostgreSQL
  • Fix in the UnitOfWork to handle autoincrement fields correctly, if an increment field value was explicitly specified (previously it queried the lastInsertId(), which fails for postgres, since it uses a sequence, which is not updated in case an id is explicitly inserted. (It might be a good idea to also move the postgres sequence in the Pgsql::insert() to the maximum inserted value to make sure that it correctly simulates autoincrement fields, and does not generate conflicting ids -> this is not done yet)
  • Add unit test
  • Add tearDown() support for the unit test framework
  • Fix 741 ticket test (it seems to have relied on a bug in the handling of autoincrement fields: basically a second record was inserted silently) The correct state is DIRTY instead of TDIRTY.
  • Put the new unit test onto the exclusion list because it interferes with the Query test (despite using tearDown() to reset the connection). It also relies explicitly on PostgreSQL.
Comment by Gergely Kis [ 25/Feb/10 ]

Increasing priority to critical because this is a major issue with the current 1.2 series.

Comment by Enrico Stahn [ 17/Jun/10 ]

Environment: doctrine 1.2.4, symfony 1.4

I moved our project from doctrine 1.2.1 to 1.2.4. The build process stops because of this patch. We are using primary keys with an alias. It seems that the generation of the sequence name in the build-process is different to the one used in UnitOfWorks.

Example:

Authority:
columns:
a_id:

{ name: a_id as id, type: integer, primary: true, autoincrement: true }

name:

{ type: string }

This will generate a sequence called "authority_a_id", but it will try no "currval" the sequence "authority_id".

I'll try to provide a UnitTest. The current seems broken.

php -l Ticket/DC521TestCase.php
PHP Parse error: syntax error, unexpected $end, expecting T_FUNCTION in Ticket/DC521TestCase.php on line 143

Parse error: syntax error, unexpected $end, expecting T_FUNCTION in Ticket/DC521TestCase.php on line 143
Errors parsing Ticket/DC521TestCase.php

Comment by Enrico Stahn [ 17/Jun/10 ]

@see DC-747





[DC-518] Generated *Table.class.php should contain a getInstance() method Created: 23/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Symfony 1.3 with Doctrine 1.2 on Debian 5.0 Linux



 Description   

I'm using the symfony framework but assume that the following only affects the classes that were auto generated by Doctrine.

When doctrine generates the model classes for e.g. the sql table "manage_users" it generates:

 
  lib/model/doctrine/ManageUsers.class.php                           <- extends Doctrine_Table
  lib/model/doctrine/ManageUsersTable.class.php                 <- extends BaseManageUsers
  lib/model/doctrine/base/BaseManageUsers.class.php       <- extends sfDoctrineRecord

As far as I understand the ManageUsersTable class is supposed to be autoloaded by Doctrine (cf. ATTR_AUTOLOAD_TABLE_CLASSES) and injected into
the class returned by Doctrine::getTable('ManageUsers').

The first problem is that it is hard to figure out for newbies how to access methods in this class because they try all means to instanciate it or looking for static methods but eventually fail

The second problem is that using it this way, the IDE auto completion feature has no chance to figure out that the returned object offers methods defined in ManageUsersTable.class.php, it can only know that the results is an instance of Doctrine_Table.

The third problem is that one has to repeatingly write Doctrine::getTable("ManageUser") in the source code which is quite error prone - or did you notice that I missed an "s" in the example just given The IDE has again no chance to spot this.

A simple solution to all problems would be an auto generated getInstance method like this:

 
 class ManageUsersTable extends Doctrine_Table {
    /** Returns an instance of this class.
     *
     * @return ManageUsersTable
     */
    public static function getInstance() {
        return Doctrine::getTable('ManageUsers');
    }
 }

This way one could write ManageUs<AUTOCOMPLETION>::getInstance()->get<AUTOCOMPLETION>(); and there would be far less typo bugs!

bye,

christian






[DC-517] [PATCH] copy() method ignores INDEXBY associations Created: 22/Feb/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

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

Attachments: Text File copy.patch    

 Description   

relations are copied by [] instead of [$key], which will remove any INDEXBY assocations. See attached patch.






[DC-513] Complex HAVING clause generates incorrect SQL in Doctrine_Query::getCountSqlQuery() and Doctrine_Query::getLimitSubquery() [patch included] Created: 21/Feb/10  Updated: 11/Mar/10  Resolved: 11/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Pager, Query
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

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

php 5.3.0


Attachments: Text File Query.patch    

 Description   

I created a DQL query with a complex having clause, such as:

Doctrine_Query::create()
->from('Record r')
->addSelect('r.*')
->addSelect('((ACOS(SIN( ... AS miles') // Determines miles from lat/longs
->having('(r.location IS NULL) OR (miles <= r.location)');

The query works fine when executed by itself. However, when passed to Doctrine_Query::getCountSqlQuery(), it strips the r.location from the select fields, however this field remains in the having clause, and SQL errors out saying that it can't find the field. Then, when it is passed to Doctrine_Query::buildSqlQuery(true) by Doctrine_Pager->execute() (true designates to use getLimitSubquery()), getLimitSubquery() does the same thing and doesn't include these fields in the subquery.

I built a patch that I am using for my application to get around this. What it does is it searches for anything matching `[a-z0-9_]`.`[a-z0-9_]` in getCountSqlQuery() and getLimitSubquery() in the HAVING clause (for instance, would match `r`.`location`) and adds the field to the select query. This is a patch for Doctrine-1.2.1, and I haven't tested it extensively, so I'm not sure if it breaks anything, however in the quick testing I have done it seems to be working OK.

I greatly appreciate all the work the Doctrine team has done for this amazing ORM - keep up the good work! If I can be of any other assistance, please let me know.



 Comments   
Comment by Jonathan H. Wage [ 11/Mar/10 ]

Thanks for the issue and patch.





[DC-512] Wrong sorting of migration files Created: 20/Feb/10  Updated: 02/Mar/10  Resolved: 02/Mar/10

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

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

Attachments: File patch-migration-sort.diff    

 Description   

If I name migration files just as 1.php, 2.php, ..., 10.php, then sorting goes wrong and they will be read in this order: 1.php, 10.php, 2.php, ....

I fixed it just by replacing

ksort($classesToLoad);

with

ksort($classesToLoad, SORT_NUMERIC);





[DC-511] Inflector::classify is slow Created: 19/Feb/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

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

php5.3.1, macosx 10.6.2


Attachments: Text File patch_dc_511.patch    

 Description   

The Doctrine_Inflector::classify is used a lot while doing batch script. The implementation is based on preg_replace_callback method which is slow. By adding a small cache layer this can speed up Doctrine



 Comments   
Comment by Thomas Rabaix [ 19/Feb/10 ]

The patch ...





[DC-510] setColumnOption(s) doesn't update _identifier when setting column as primary (symfony 1.4.2) Created: 18/Feb/10  Updated: 02/Mar/10  Resolved: 02/Mar/10

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

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

symfony 1.4.2



 Description   

class PlgSlide extends BasePlgSlide
{
public function setTableDefinition()

{ parent::setTableDefinition(); $this->setColumnOptions('domain_id', array('primary' => true)); }

...
doesn't work, domain_id field is not added as part of identifier for PlgSlide table records


class PlgSlide extends BasePlgSlide
{
public function setTableDefinition()

{ parent::setTableDefinition(); $this->hasColumn('domain_id', 'integer', 4, array( .... other field option options here 'primary' => true )); }

do work as expected.

I've made some investigation and found code fragment at Table.php, in function setColumn, line 1373:
if (isset($options['primary']) && $options['primary']) {
...
$this->_identifier = (array) $this->_identifier;

but no such functionality for setColumnOption function, Table.php, line 1235






[DC-508] All but the first migrations fail with PostgreSQL [patch included] Created: 17/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Bug Priority: Blocker
Reporter: Elnur Abdurrakhimov Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: File patch-doctrine-migration-pgsql-2.diff     File patch-migration-pgsql.diff     File patch-migrations.diff    

 Description   

The problem is in this method:

protected function _createMigrationTable()
{
    if ($this->_migrationTableCreated) {
        return true;
    }

    $this->_migrationTableCreated = true;

    try {
        $this->_connection->export->createTable($this->_migrationTableName, array('version' => array('type' => 'integer', 'size' => 11)));

        return true;
    } catch(Exception $e) {
        return false;
    }
}

When migration_version table doesn't exist, everything works like it should. But subsequent migrations fail, because after failing at creating migration_version table every subsequent queries in that transaction fail.

It works flawlessly with MySQL, but fails with PostgreSQL.



 Comments   
Comment by Elnur Abdurrakhimov [ 20/Feb/10 ]

My previous patch broke MySQL migrations. This new patch resolves that problem.

My solution is not neat, but at least migrations work and I can continue developing my project.

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

This isn't really a good patch. I don't wanna have driver specific conditional statements like that.

What about if we started and committed our own transaction for the create table so that everything else is in another transaction and would not conflict.

Comment by Elnur Abdurrakhimov [ 15/Mar/10 ]

This time solution is neater.

Comment by Elnur Abdurrakhimov [ 15/Mar/10 ]

Provided a patch with a neater solution.

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

Thanks for following up on this and fixing the root cause of the problem.





[DC-506] Doctrine_Adapter_Statement_Oracle missing fetch statement in fetchAll() Created: 17/Feb/10  Updated: 02/Mar/10  Resolved: 02/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.0.12, 1.0.13, 1.0.14, 1.1.4, 1.1.5, 1.1.6, 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
Fix Version/s: 1.2.2

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

Linux RHEL5 (discovered in Symfony, but crosschecked with Doctrine 1.x source)



 Description   

It looks like the developer changed their mind on how to set the flags halfway through coding, as the $flags variable is not used. Critically, if the default FETCH_BOTH is specified, then no fetch is performed. I also did some testing with the OCI_BOTH constant, and could not get it to return the desired results (only enumerated results were returned). I also tried replacing OCI_BOTH with OCI_NUM + OCI_ASSOC with the same results.

I guess this should either throw an exception (not supported) or be fixed to return the appropriate results.

Line 361 in v1.2

        $flags = OCI_FETCHSTATEMENT_BY_ROW + OCI_ASSOC;

        $int = $fetchStyle & Doctrine::FETCH_COLUMN;

        if ($fetchStyle == Doctrine::FETCH_BOTH) {
            $flags = OCI_BOTH;
            $numberOfRows = @oci_fetch_all($this->statement, $data, $skip, $maxrows, OCI_FETCHSTATEMENT_BY_ROW + OCI_ASSOC + OCI_RETURN_LOBS);
        } else if ($fetchStyle == Doctrine::FETCH_ASSOC) {





[DC-505] Doctrine_Cache_Db can be much faster Created: 16/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

Status: Closed
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
Fix Version/s: 1.2.2

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

Intel(R) Pentium(R) 4 CPU 3.20GHz, Redhat


Attachments: File doctrine_cache_speedup.diff    

 Description   

Each Doctrine_Cache_Db->_doFetch() invocation costs about 50 ms on my PC(depending on the data of course). By using built-in pack() function performance can be increased 700x times. Each invocation now costs about 0.07 ms. The change is very considerable for pages with multiple queries.



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

Thanks for the issue and patch!





[DC-504] toArray not using lazy loading Created: 16/Feb/10  Updated: 10/Mar/10  Resolved: 02/Mar/10

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

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

Ubuntu 9.10, PHP 5.2, Zend Framework 9.6



 Description   

When selecting specific fields in a doctrine query, and calling toArray, the resulting arrays ignore the selected fields and load all values from the database record.

$phones = Doctrine_Query::create()
        ->select('ph.phone_type')
        ->from('Phone ph')
        ->orderBy('ph.phone_type')
        ->limit(2)
        ->execute()
        ->toArray();

The above query when dumped returns...

Array
(
    [0] => Array
        (
            [id] => 1
            [status] => 
            [phone_type] => business
            [number] => 8003041538
            [current_status_id] => 1
            [created_at] => 2010-01-08 15:08:34
            [updated_at] => 2010-01-08 15:08:34
        )

    [1] => Array
        (
            [id] => 2
            [status] => 
            [phone_type] => business
            [number] => 2052052055
            [current_status_id] => 1
            [created_at] => 2010-02-14 13:07:12
            [updated_at] => 2010-02-14 13:07:12
        )

)


 Comments   
Comment by David Ash [ 16/Feb/10 ]

After a quick test, using ->execute(array(), Doctrine_Core::HYDRATE_ARRAY) returns the expected results, but toArray does not.

Comment by Brian B. [ 10/Mar/10 ]

Hi,

Using the latest SVN from the 1.2 branch, this code returns null values for the fields that are not part of the select call. For example:

Doctrine_Query::create()
                ->select('venue_id, extended_name')
                ->from('Model_Venue v')
                ->execute()
                ->toArray();

Will return the following:

array
 0 => 
    array
      'venue_id' => string '160' (length=3)
      'number' => null
      'venue' => null
      'extended_name' => string 'Long Venue Name 160' 
  1 => 
    array
      'venue_id' => string '161' (length=3)
      'number' => null
      'venue' => null
      'extended_name' => string 'Long Venue Name 161' 

I believe it should not include the `number` and `venue` columns within the array? The correct SQL query is returned only giving me the venue_id and extended_name columns. Not sure if that is a bug/feature since I did not find it within the documentation.

I am running a MS SQL 2005 server, PHP 5.3.1 w/ pdo_mssql Apache 2.2.14. Thanks.

Brian





[DC-503] Migrations task generates wrong diff for long table names Created: 16/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

All


Attachments: Text File 0001-migrations-fix.patch     File 1266313871_version1.php     File schema.yml    

 Description   

With the attached schema, a migrations diff is generated after an initial setup of the project, although
there are no differences at all. The two models are exactly identical, the only difference is the
lenght of their table names. A diff is detected for model "Institute", but not for the one called "Institut".

The reason is in the generation of the foreign keys (Doctrine_Connection line 1624), which
generates an abbreviated foreign key name for names longer than 64 characters. This
is true in the "to" models of the migration, but not in the "from" models.



 Comments   
Comment by Robert Gruendler [ 16/Feb/10 ]

I couldn't find a way to alter the max_identifier_length property of Doctrine_Connection, so i've created a patch
that introduces an ATTR_MAX_IDENTIFIER_LENGTH Connection attribute. If set, the maxLength is taken from
the attribute, if not set, it defaults to 64 like now.





[DC-500] Duplicate Index for foreign key(MySQL) Created: 15/Feb/10  Updated: 02/Mar/10  Resolved: 02/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

Type: Bug Priority: Major
Reporter: Sven Pöche Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

If an index with the same as the foreign key field exists and is not an array, and it is not the last in the list, adds it twice

SUGGESTION SOLUTION:

Doctrine/Export/Mysql.php (136): $found = $found || ($local == $definition['fields']);






[DC-495] Allow the end of line style to be set in the record builder Created: 12/Feb/10  Updated: 29/Mar/10  Resolved: 29/Mar/10

Status: Resolved
Project: Doctrine 1
Component/s: Record, Schema Files
Affects Version/s: None
Fix Version/s: 1.2.2

Type: Improvement Priority: Major
Reporter: Jordi Boggiano Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 1
Labels: None
Environment:

All


Attachments: Text File doctrine-eolstyle.patch    

 Description   

When building base models on multiple boxes with different operating systems, the use of PHP_EOL in the model builder is problematic since when you rebuild you basically change every line of every file, leading to huge commits that are impossible to review.

I therefore added an eolStyle option to the Doctrine_Import_Builder class that allows you to specify which EOL markers to use.

It works perfectly fine here and the patch is attached, if the option is not specified the code remains the same as before btw so no performance loss or any possible BC break.

Thanks



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

The applied fix is NOT correct. My patch did it at the end of the file generation specifically because the file contains stuff generated by many other classes (or something).

With the current state, and eolStyle set to \n, the result looks like this, which is completely wrong:

{\n
$this->setTableName('foo);\n
$this->hasColumn('id', 'integer', 4, array(\r\n
'type' => 'integer',\r\n

Please revert and apply the original patch that was working perfectly fine..





[DC-493] method bracketExplode when tablename contains "Join" Created: 11/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Windows 7 / Linux Ubuntu, Apapche 2.2, PHP 5.3


Attachments: GIF File bracketExplode.gif     GIF File ScreenHunter_01 Feb. 11 15.48.gif    

 Description   

Hello,
I'm using Symfony 1.4.1 with Doctrine (I imagine that the doctrine's version is 1.2.1), and I have a strange behavior because my table name is "piece_jointe", so it contains "JOIN" keyword inside.
In Doctrine_Query_Tokenizer class, the method bracketExplode explode string with a regular expression "#(JOIN)#i", so the table name is exploded and nothing works after that.

do you think it's possible to write a better regular expression to avoid this behavior ? Maybe add spaces after JOIN : "#(JOIN )#i but if there is a line break... or "#(JOIN[\s \n])#i"
For now, I'll rename the table !

Thanks a lot,
best regards
Etienne






[DC-492] Nested set behavior not correctly working (Doctrine_Node_NestedSet::shiftRlValues) (Updated) Created: 11/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Windows XP, Wampserver 2.0 with php 5.2.9-2 and mysql 5.1.33 and apache 2.2.11



 Description   

When using the code:

main.php
    $parent = new Category();
    $parent->setName('Parent');
    $parent->save();
    Doctrine_Core::getTable('Category')->getTree()->createRoot($parent);
    
    $child = new Category();
    $child->setName('Child');
    $child->save();
    
    $child->getNode()->insertAsLastChildOf($parent);

Now it throws an exception with the message:

"Unknown component alias Category" from the Doctrine_Query_Abstract class, line 743.

Tracking down the problem, it seems that in the method shiftRlValues there was a problem:

NestedSet.php
    // shift left columns
        $componentName = $this->_tree->getBaseComponent();

        $qLeft  = Doctrine_Core::getTable($componentName)
            ->createQuery()
            ->update();

        $qRight = Doctrine_Core::getTable($componentName)
            ->createQuery()
            ->update();

        $qLeft = $qLeft->set($componentName . '.lft', $componentName.'.lft + ?', $delta)
                       ->where($componentName . '.lft >= ?', $first);
        $qLeft = $this->_tree->returnQueryWithRootId($qLeft, $rootId);

        $resultLeft = $qLeft->execute();
        
        // shift right columns
        $qRight = $qRight->set($componentName . '.rgt', $componentName.'.rgt + ?', $delta)
                         ->where($componentName . '.rgt >= ?', $first);

        $qRight = $this->_tree->returnQueryWithRootId($qRight, $rootId);

        $resultRight = $qRight->execute();


Making a comparison with the NestedSet class in the 1.0 series, realized that the update methods need the component name resulting in:

NestedSet.php
    // shift left columns
        $componentName = $this->_tree->getBaseComponent();

        $qLeft  = Doctrine_Core::getTable($componentName)
            ->createQuery()
            ->update(<b>$componentName</b>);

        $qRight = Doctrine_Core::getTable($componentName)
            ->createQuery()
            ->update(<b>$componentName</b>);

        $qLeft = $qLeft->set($componentName . '.lft', $componentName.'.lft + ?', $delta)
                       ->where($componentName . '.lft >= ?', $first);
        $qLeft = $this->_tree->returnQueryWithRootId($qLeft, $rootId);

        $resultLeft = $qLeft->execute();
        
        // shift right columns
        $qRight = $qRight->set($componentName . '.rgt', $componentName.'.rgt + ?', $delta)
                         ->where($componentName . '.rgt >= ?', $first);

        $qRight = $this->_tree->returnQueryWithRootId($qRight, $rootId);

        $resultRight = $qRight->execute();


Now the queries work correctly!.

.............

I seems the cause of the problem was the fact of overwriting createQuery method from Doctrine_Table

kcDoctrineTable.class.php
  public function createQuery($alias = '')
  {
    $alias = empty($alias) ? $this->getAlias() : trim($alias);
    $alias = ' '.$alias;
    
    $class = $this->getAttribute(Doctrine_Core::ATTR_QUERY_CLASS);

    return Doctrine_Query::create(null, $class)->from($this->getComponentName().$alias);
  }
  public function getAlias()
  {
    $name  = substr(get_class($this), 0, -5);
    $name  = sfInflector::underscore($name);
    $names = explode('_', $name);
    array_walk($names, create_function('&$v, $k', '$v = $v{0};'));
    $alias = implode('', $names);
    
    return $alias;
  }

I was trying to give and alias always by default:

Category -> c
CategoryAttribute -> ca
CategoryAttributeExtension -> cae

This breaks shiftRlValues method from NestedSet because there, it is used the component name as alias, and when createQuery creates a "from" part with a different alias the whole query crush.

It would be nice to have this feature in a future release.



 Comments   
Comment by Jonathan H. Wage [ 02/Mar/10 ]

Can you provide these changes as a patch? It's hard to identify the changes and understand everything without it.

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

I was able to pull your changes out of the pasted code. For future issues please create a patch as it is easier to see exactly what changes you made.





[DC-488] Cannot parse table name including 'join' Created: 10/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Bug Priority: Major
Reporter: Chang-gun Lee Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

php 2.3.11, Windows 7 64bits


Attachments: File 9998TestCase.php    

 Description   

Cannot parse table name including 'join'.

$q = new Doctrine_Query();
$q->from('MyJoinProblem');

In above code, I want to query like 'SELECT m.id AS m__id FROM MyJoinProplem m'.
But, Doctrine try to find 'My' table and 'Problem' table.
Table name is 'MyJoinProblem'.






[DC-487] Worng docs: @return docs of some methods in Doctrine_Query_Abstract class are worng. Created: 10/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Bug Priority: Major
Reporter: TANAKA Koichi Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None

Attachments: File docfix.diff    

 Description   

@return docs of getSqlQueryPart should be mixed.
@return docs of setSqlQueryPart, addSqlQueryPart, removeSqlQueryPart, removeDqlQueryPart, copySubqueryInfo, useResultCache, useQueryCache, expireResultCache, expireQueryCache, setResultCacheLifeSpan and setQueryCacheLifeSpan should be Doctrine_Query.

This issue is also reported in the user ml. http://groups.google.com/group/doctrine-user/browse_thread/thread/ee5d40f03242af8b






[DC-483] Indentifiers are not quoted in queries build for Nested Relations (patch included) Created: 08/Feb/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Resolved
Project: Doctrine 1
Component/s: Native SQL, Query, Relations
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

Type: Bug Priority: Blocker
Reporter: Elnur Abdurrakhimov Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu, PHP, MySQL


Attachments: File patch.diff    

 Description   

It was OK using reserved words as column names before I started using Nested Relations: queries started to fail because Doctrine_Core::ATTR_QUOTE_IDENTIFIER is ignored by query builder for Nested Relations.

I solved this problem by wrapping identifiers with Doctrine_Formatter::quoteIdentifier() in several places. I'm providing a patch for your to review and commit.

Thanks.






[DC-482] $data passed to foreach is wrong Created: 07/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Apache/2.2.12 (Win32) DAV/2 mod_ssl/2.2.12 OpenSSL/0.9.8k mod_autoindex_color PHP/5.3.0 (xampp 1.7.3)



 Description   

Calling a query that doesn't use all tablecols gives php warnings such as:

Errorcode: E_WARNING [php warning] (2)
Message: Invalid argument supplied for foreach()
File: Record.php
Line: 1151

--------------------------------------------------------------
$data = empty($data) ? $this->getTable()->find($id, Doctrine_Core::HYDRATE_ARRAY) : $data;
foreach ($data as $field => $value) {
--------------------------------------------------------------

$data is empty but not an array.






[DC-480] Since 1.2, records can't have columns named "options" anymore Created: 06/Feb/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Documentation, Record
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

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


 Description   

Since Doctrine 1.2, Doctrine_Record_Abstract has a new getOptions() method. This forbids any models to have some columns named "options" (and this breaks compatibility with older versions).

I think this should be mentioned in documentation and release notes. And maybe, an exception should be thrown if a reserved doctrine keyword (options, table...) is defined as column name.

Of course, a better resolution would to not make the word "options" a reserved keyword but I don't know it's really possible in 1.2.x.






[DC-475] generate-migrations-diff is producing bogus migrations (drops the whole database) Created: 02/Feb/10  Updated: 03/Mar/10  Resolved: 01/Mar/10

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

Type: Bug Priority: Minor
Reporter: Matthew Hughes Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 4
Labels: None
Environment:

Vanilla sandbox on version 1.2.1 and 1.2.0
both sqlite and mysql, so its not driver dependant



 Description   

Replicating the bug:
1. unzip vanilla sandbox.
2. create schema file with entity
3. run ./doctrine build-all
4. modify schema, add column to entity.
5. run ./doctrine generate-migrations-diff

Expected behaviour:
generates migration wich adds column to entity.

Real behaviour:
Drops entity from database

Similar issue:
http://groups.google.com/group/doctrine-user/browse_thread/thread/8b4a0fc0778a388a/79446784623b8497?lnk=gst&q=1.2.1+migration



 Comments   
Comment by Matthew Hughes [ 02/Feb/10 ]

I've just tested on Doctrine 1.1.6 sandbox, and the expected behaviour is met.

Cheers.

Comment by Kyle Spraggs [ 02/Feb/10 ]

I can confirm this behavior. I have attached a few pastebin posts for more information.

Steps:
1. Create schema (http://pastebin.com/f1726889)
2. ./doctrine build-all
3. Modify schema (http://pastebin.com/d5ad9b0ee)
4. ./doctrine generate-migrations-diff (http://pastebin.com/d1c30e6f5)

Comment by Michael Gatto [ 02/Mar/10 ]

Thanks for this fix, Johnathan; its much appreciated.

Comment by Michael Gatto [ 03/Mar/10 ]

This seems to still be broken.

I updated my install to the latest SVN to get this fix and ran "doctrine.php generate-migrations-diff" with a changed schema and unchanged model classes. The resulting migration is identical to the full DB drop-recreate as I had before this fix.

Comment by Matthew Hughes [ 03/Mar/10 ]

I'm getting the expected behaviour
on 1.2 branch. you might be using the wrong branch/tag.

thanks jwage btw.

Comment by Kyle Spraggs [ 03/Mar/10 ]

I checked out the 1.2 branch and do not encounter the same error as before but I still am unable to get migrations to function. I'm getting the error message "Could not generate migration classes from difference" using the following settings:

doctrine.data_fixtures_path = APPLICATION_PATH "/configs/data/fixtures"
doctrine.sql_path = APPLICATION_PATH "/configs/data/sql"
doctrine.migrations_path = APPLICATION_PATH "/configs/migrations"
doctrine.yaml_schema_path = APPLICATION_PATH "/configs/schema"
doctrine.models_path = APPLICATION_PATH "/models"

doctrine.generate_models_options.pearStyle = true
doctrine.generate_models_options.generateTableClasses = false
doctrine.generate_models_options.generateBaseClasses = true
doctrine.generate_models_options.baseClassPrefix = "Base_"
doctrine.generate_models_options.baseClassesDirectory =
doctrine.generate_models_options.classPrefixFiles = false
doctrine.generate_models_options.classPrefix = "Model_"

$doctrineConfig = $this->getOption('doctrine');
$manager = Doctrine_Manager::getInstance();
$manager->setAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
$manager->setAttribute(Doctrine_Core::ATTR_MODEL_CLASS_PREFIX, 'Model_');
$manager->setAttribute(Doctrine_Core::ATTR_MODEL_LOADING, Doctrine_Core::MODEL_LOADING_PEAR);
$manager->setAttribute(Doctrine_Core::ATTR_VALIDATE, Doctrine_Core::VALIDATE_ALL);

Doctrine_Core::loadModels($doctrineConfig['models_path']);

$conn = Doctrine_Manager::connection($doctrineConfig['dsn'], 'doctrine');
$conn->setAttribute(Doctrine_Core::ATTR_USE_NATIVE_ENUM, true);

I'm invoking the CLI by using:

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





[DC-472] In the relatedExists method of the Doctrine_Record class the exception is incorrectly thrown imho Created: 01/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Windows XP, WAMP 2.0, PHP 5.2.11


Attachments: Text File Doctrine_Record_relatedExists.txt    

 Description   

When using the result of a:

test.php
$q = Doctrine::createQuery()
        ->from('User u')
        ->leftJoin('Role r');

$users = $q->execute();

now if we want to iterate and know if exists the according role for each user

test.php
foreach ($users as $user)
{
  $role_name = $user->relatedExists('Role') ? $user->getRole()->getName() : '';
}

the exception in the relatedExists method will be thrown:

test.php
public function relatedExists($name)
    {
        $newReference = false;
        if ( ! $this->hasReference($name)) {
            $newReference = true;
        }

        $reference = $this->$name;
        if ( ! $reference instanceof Doctrine_Record) {
            throw new Doctrine_Record_Exception(
                'You can only call relatedExists() on a relationship that '.
                'returns an instance of Doctrine_Record'
            );
        }
        $exists = $reference->exists();

        if ($newReference) {
            $this->clearRelated($name);
        }

        return $exists;
    }

because the according role record does not exist for some users ( a user just could have one record).

it could be better this way:

test.php
public function relatedExists($name)
    {
        $newReference = false;
        if ( ! $this->hasReference($name)) {
            $newReference = true;
        }

        $reference = $this->$name;
        if ( ! $reference && ! $this->getTable()->hasRelation($name)) {
            throw new Doctrine_Record_Exception(
                'You can only call relatedExists() on a relationship that '.
                'returns an instance of Doctrine_Record'
            );
        }

        $exists = $reference ? $reference->exists() : false;

        if ($newReference) {
            $this->clearRelated($name);
        }

        return $exists;
    }

With this change, this method can be used to check newly created user objects or some retrieved from the db (left join with role) smoothly.



 Comments   
Comment by Jonathan H. Wage [ 02/Mar/10 ]

Hi, I was able to copy and paste your change out of the comment, but when I apply it and run the tests. It seems to break something, which I expected. Your changes allows collections through now and it calls a method that doesn't exist on Doctrine_Collection. Give your change a try and run the tests, maybe you can provide a more complete patch and we can include it for 1.2.2 release. Thanks, Jon

Comment by Jonathan Nieto [ 09/Mar/10 ]

Hi, I just made the patch and ran it against the tests. No errors arose.

I have the following explanation for the patch:

The main difference with the previous relatedExists is when checking a relation not serialized in the database but that already exists in the current record. Then the current related exists will return true and the previous relatedExists will return false because that object does not exist in the database.

Take in count that there are two states of the object:
1.- When retrieve with findOne without any relation
2.- When retrieve leftJoin or innerJoin with a relation

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

Thanks for the issue and patch!





[DC-469] getAccessors and getMutators shows notices if they are not set Created: 01/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.0
Fix Version/s: 1.2.2

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


 Description   

It's a very minor problem I know that. However when I try to use getAccessors() or getMutators() functions, if nothing is set on the table definitions, it throws some notices on the php (on error_reporting all) that such an index does not exists. As there is no such index to be found it returns null instead of expected array (empty if there is no mutators for that table)

public function getAccessors()
{
$componentName = $this->_table->getComponentName();
if (!isset(self::$_customAccessors[$componentName]))

{ return array(); }

return self::$_customAccessors[$componentName];
}

such a code solves the problem and not notices is thrown and empty array is returned if there is no accessors. Same kind of an improvement is required for getMutators too

I know that this is a minor issue however I wanted to inform you.






[DC-468] Project directories that have underscores (ie my_project) in the name get replaced with slashes (my/project) when generating models Created: 01/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Ubuntu Hardy



 Description   

I have a project name that contains an underscore. When I run the doctrine CLI to create the models from the yaml file, something string replaces all underscores with slashes.

So where I would be expecting the models to be generated in 'my_project/application/models', it is instead being generated in 'my/project/application/models'



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

This should already be fixed in the latest 1.2 in SVN and will be in 1.2.2





[DC-460] Doctrine_Cache_Apc/Core changes in 1.2 cause instability and crashes Created: 27/Jan/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Caching
Affects Version/s: 1.2.0, 1.2.1
Fix Version/s: 1.2.2

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

Issue Links:
Reference
relates to DC-390 doctrine_cache_keys bigger than 1mb Open

 Description   

Since upgrading to Doctrine 1.2 my application has begun to get increasingly slower as hours elapse. I've pinpointed the cause to the new doctrine_cache_keys feature.

I've found at least three issues with this new method.

First

The key cache does not track enforce unique entries, thus multiple entries can be in the cache. See:

    protected function _saveKey($key)
    {
        $keys = $this->fetch($this->_cacheKeyIndexKey);
        $keys[] = $key;

        return $this->save($this->_cacheKeyIndexKey, $keys, null, false);
    }

    public function _deleteKey($key)
    {
        $keys = $this->fetch($this->_cacheKeyIndexKey);
        $key = array_search($key, $keys);
        if ($key !== false) {
            unset($keys[$key]);

            return $this->save($this->_cacheKeyIndexKey, $keys, null, false);
        }

        return false;
    }

Second

The doctrine_cache_key is being updated on every cache save or delete. With any caching strategy (APC, Memcached, Xcache) cache writes for the same key are (naturally) serialized. This leads to the "timebomb" situation described here: http://t3.dotgnu.info/blog/php/user-cache-timebomb.html

The problem is exarcerbated by the infinitely increasing size of the doctrine_cache_key array noted above. Depending on the caching engine, the lock time increases as well (APC & XCache free the previous entry inside the lock). This causes the application to spiral out of control, even with relatively trivial loads.

Personally, I don't think the "benefit" of having prefix/regex deletes is worth having this. Jon, you suggested having it disabled by default, but even with it enabled, this problem is reintroduced when someone decides to use it.

Third

For most (maybe all?) cache engines the doctrine_cache_key seems entirely unnecessary.

  1. APC
    • apc_cache_info('user') returns the list of cache entries
  2. Memcached
    • $memcache->getExtendedStats('cachedump', $slabId) can return the list of cache keys
  3. XCache
    • According to the API docs xcache_list() behaves similar to apc_cache_info()
  4. DB
    • a simple query can get this
  5. Array
    • array_keys() ?

Summary

As this is currently broken for production use I intend to immediately fix both the first and second items above by preventing duplicate entries and disabling the doctrine_cache_keys behavior by default.

With more input/discussion I think the long term solution is to use the tools provided by the engines to get a list of keys, rather than maintain a list. I'd be willing to develop this as long as it is approved.



 Comments   
Comment by David Abdemoulaie [ 27/Jan/10 ]

I fixed the first issue in the following revision:

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

cache_keys entries are now stored as the key of an array. This allows for simple uniqueness enforcement, as well as being significantly faster for deletion: array_key_exists is O(log n), array_search is O( n ).

Comment by Roman S. Borschel [ 27/Jan/10 ]

I have to agree with this feature turning out to be extremely problematic. See DC-390 for a related problem (I linked it to this one). It should really be disabled by default, at least. Of course it can not be stripped out of 1.2.

We will strongly reconsider it in 2.0.

Comment by David Abdemoulaie [ 27/Jan/10 ]

Jon,

I was about to backport the 2.0 code to allow enabling/disabling the use of doctrine_cache_keys, but I noticed that it is already in 1.2 at the last second:

    public function save($id, $data, $lifeTime = false, $saveKey = true)

I think the 2.0 method is the better way to go about doing this, because afaik users generally don't call save() directly, the Doctrine code does. Thus there's really no way to disable this class-wide.

I don't know if such an API change is acceptable to you in 1.2 though. I think it should be done due to the basic unusability of 1.2 caching in production.

If not, can we just change the $saveKey param default to false?

Comment by David Abdemoulaie [ 29/Jan/10 ]

Per discussion on IRC I have completely removed the doctrine_cache_keys functionality from Doctrine_Cache.

The deleteByPrefix(), deleteBySuffix(), and deleteByRegex() methods are still present, but they use driver-specific methods to retrieve a list of cache keys. Due to this the following methods have been deprecated and removed:

  • Doctrine_Cache_Driver::count() — Counting is no longer possible or relevant because the items cached by Doctrine are indistinguishable from items cached from other parts of your application(s)
  • Doctrine_Cache_Driver::deleteAll() — Same as above.

The only other API change made is the signature of the Doctrine_Cache_Interface::save() methods:

    public function save($id, $data, $lifeTime = false, $saveKey = true)

is now

    public function save($id, $data, $lifeTime = false)

See r7074 and r7075

Comment by David Abdemoulaie [ 29/Jan/10 ]

Ported changes to 2.0 trunk in r7076





[DC-459] Typo in Doctrine_Validator_Email Created: 27/Jan/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Resolved
Project: Doctrine 1
Component/s: Validators
Affects Version/s: 1.1.6
Fix Version/s: 1.2.2

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

Attachments: Text File fix_typo.patch    

 Description   

Typo in comments for Doctrine_Validator_Email->_checkMx()

Patch attached.






[DC-458] Doctrine_Validator_Ip fails on IPV6 IP addresses. Created: 27/Jan/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

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

Attachments: Text File fix_ip_validator_to_validate_ipv6_and_ipv4.patch    

 Description   

Doctrine_Validator_Ip->validate() uses ip2long() in order to validate IP addresses.

However, ip2long() only works for IPv4 addresses, and not IPv6 addresses.

Attached is a patch to use filter_var which validates both IPv4 and IPv6 properly.






[DC-446] Doctrine_Record_Generator::createClass with Doctrine_Record_Listener Created: 25/Jan/10  Updated: 02/Mar/10  Resolved: 02/Mar/10

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

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

Attachments: File diff    

 Description   

Doctrine_Record_Generator::initialize first builds the table class and then a "Doctrine_Record" from that. This is surprising, as the result is a "double conversion" from record to table and back.

Furthermore, writing files, no record listeners can be attached (see createClassFromTable)!

I therefore suggest adding the possibility to add listeners - which the builder already does! - to the Record_Generator.






[DC-441] When using PearStyle model loading and a classPrefix, the Doctrine CLI will ignore any SQL operations if model_autoloading is set to conservative Created: 20/Jan/10  Updated: 16/Mar/10  Resolved: 16/Mar/10

Status: Resolved
Project: Doctrine 1
Component/s: Cli, Import/Export, Native SQL
Affects Version/s: None
Fix Version/s: 1.2.2

Type: Bug Priority: Minor
Reporter: Jon Lebensold Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Mac OS X, PHP 5.2.9



 Description   

When using PearStyle model loading and a classPrefix, the Doctrine CLI will ignore any SQL operations if model_autoloading is set to conservative . If model_autoloading is set to aggressive, then everything works as expected.

Here's my Doctrine configuration:

doctrine.generate_models_options.pearStyle = true
doctrine.generate_models_options.generateTableClasses = false
doctrine.generate_models_options.generateBaseClasses = true
doctrine.generate_models_options.baseClassPrefix = "Base_"
doctrine.generate_models_options.baseClassesDirectory =
doctrine.generate_models_options.classPrefixFiles = false
doctrine.generate_models_options.classPrefix = "Model_"
; Conservative Model Loading:
doctrine.model_autoloading = 2

and my Doctrine initialization method:
protected function _initDoctrine()

{ $this->getApplication()->getAutoloader() ->pushAutoloader(array('Doctrine', 'autoload')); spl_autoload_register(array('Doctrine', 'modelsAutoload')); $doctrineConfig = $this->getOption('doctrine'); $manager = Doctrine_Manager::getInstance(); $manager->setAttribute(Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true); $manager->setAttribute( Doctrine::ATTR_MODEL_LOADING, $doctrineConfig['model_autoloading'] ); Doctrine::loadModels($doctrineConfig['models_path']); $conn = Doctrine_Manager::connection($doctrineConfig['dsn'],'doctrine'); $conn->setAttribute(Doctrine::ATTR_USE_NATIVE_ENUM, true); return $conn; }

and my doctrine.php CLI file:

require_once 'Zend/Application.php';

// Create application, bootstrap, and run
$application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/configs/application.ini'
);

$application->getBootstrap()->bootstrap('doctrine');

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



 Comments   
Comment by Owen Gray [ 02/Mar/10 ]

I hope this is an appropriate place for these comments.

I have been experimenting with the sort of ZF-Doctrine setup described by Jon. I find that everything does not work as expected with model-autoloading set to aggressive.

If the models directory contains

models/
Address.php
Base/
Address.php
User.php
User.php

operations like 'create-tables' will fail with an error message that says:

"Fatal error: Class 'Model_Base_Address' not found in /path/to/models/Address.php"

There is no error if the same operation on the same models is performed by a "pure Doctrine" CLI setup like the one in the Sandbox is used, with model-autoloading set to MODEL_LOADING_PEAR = 3. The difference is that in Jon's setup and mine, the Zend autoloader is registered before the Doctrine models autoloader. In this configuration, the Zend autoloader can find files with a 'Model_' prefix in the 'models' directory.

When the Doctrine models autoloader loads a file it puts information about the file in Doctrine_Core::_loadedModelsFiles. It looks as though Doctrine_Core::loadModels and perhaps other cli operations rely on this, assuming that if a model file has been loaded, information about that file can be obtained from Doctrine_Core::_loadedModelsFiles. That won't be the case if the Zend autoloader loaded the file, as might occur if an instance of Address.php was created before the iterator in Doctrine_Core::loadModels got to Base/Address.php.

The same problem occurs if doctrine.generate_models_options.baseClassPrefix is set to "Base." It does not occur if that parameter is set to "A" or "A/".

I considered whether this problem might be related to the ZF unfriendly restriction referred to in http://www.doctrine-project.org/jira/browse/DC-277, because classPrefixFiles is set to 'false' as it has to be for the standard ZF configuration. However, perhaps serendipitously, the cli operations seem to work fine with that setting using the 'pure Doctrine' cli setup.

I hope this information assists in sorting out this bug.

Comment by Jon Lebensold [ 02/Mar/10 ]

Owen, thanks for bringing this up. I noticed the issue, as did a number of the people on zendcasts.com.

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

I don't see any issue/bug described here. If your classes are organized to be for PEAR style and you don't have it configured to work that way, then of course it is not going to work. That is expected.





[DC-437] Connection::query() can use wrong connection Created: 19/Jan/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Attachments: Text File DC-437.patch     File DC437TestCase.php    

 Description   

As I understand, Doctrine_Connection::query() method is intended to execute DQL queries using precisely this connection.
But here is the code:

894     public function query($query, array $params = array(), $hydrationMode = null)
895     {
896         $parser = Doctrine_Query::create();                                                                                
897         $res = $parser->query($query, $params, $hydrationMode);
898         $parser->free();
899 
900         return $res;
901     }

Doctrine_Query::create() statement will create a query that is using a default connection, not the current one.



 Comments   
Comment by Eugene Janusov [ 19/Jan/10 ]

Attached proposed patch.

Comment by Eugene Janusov [ 19/Jan/10 ]

Attached test case.





[DC-434] setCharset($charset) on mysql/pgsql connections does not set Doctrine_Core::ATTR_DEFAULT_TABLE_CHARSET Created: 16/Jan/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

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

Attachments: File Mysql.php.diff     File Pgsql.php.diff    

 Description   

When calling setCharset on a connection I expect that getCharset returns the charset which is set before.

That works on sqlite and other Connections, but not on mysql and pgsql.

Doctrine_Connection_Mysql and Doctrine_Connection_Pgsql overwrite setCharset (defined in Doctrine_Configurable) and only execute their SET NAMES query and don't set Doctrine_Core::ATTR_DEFAULT_TABLE_CHARSET which is used by getCharset().

Solution would be to call

parent::setCharset($charset);

in Doctrine_Connection_Mysql::setCharset($charset) and Doctrine_Connection_Pgsql::setCharset($charset).



 Comments   
Comment by Benjamin Steininger [ 03/Feb/10 ]

Two diffs for the files





[DC-428] Bug on DropDB on Oracle. The sequence isn't not correct Created: 15/Jan/10  Updated: 11/Mar/10  Resolved: 11/Mar/10

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

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

Attachments: Text File Oracle.php.patch    

 Description   

The sequence of drop database is not correct.

I change this in my patch.

Thank's



 Comments   
Comment by Miloslav "adrive" Kmet [ 31/Jan/10 ]

Hi Bertrand,

Can you provide more informations on this issue? Some test cases, oracle error messages, oracle settings..

You are proposing to remove the double quotes from DROP TABLE statements. You can turn identifier quoting on and off. When you have ATTR_QUOTE_IDENTIFIERS to on, all your identifier names are double quoted in oracle and if you do something like
SELECT * FROM user_tables, the TABLE_NAME column contains table names lovercased. So you need the double quotes in DROP TABLE statements. If your table name is "my_table" and you do DROP TABLE my_table; you get an error about nonexistent table. You need to do DROP TABLE "my_table". That's exactly what doctrine does now.

Another scenario is doublequotes turned off. So all your tables are handled in oracle uppercased. So my_table is internally handled as MY_TABLE. That's alredy what you recieve from USER_TABLES. And when you do DROP TABLE "MY_TABLE" that is the same as DROP TABLE my_table.

I use this heavily in both cases and I have no problems with that.

The issue with I.SEQUENCE_OWNER in DROP SEQUENCE statement I fixed in r6896 (http://trac.doctrine-project.org/changeset/6896).

Comment by Bertrand Zuchuat [ 31/Jan/10 ]

Hi,

The symfony use the last version 1.2.1 revision 6894 and the change is on 6896.

A release date for version 1.2.2 ?

Thank's for your help.

Comment by Miloslav "adrive" Kmet [ 31/Jan/10 ]

Just update it yourself with svn up or use your version in YOUR_PROJECT/lib/vendor/doctrine.





[DC-425] I18n - Can't create lang column as varchar(5) Created: 14/Jan/10  Updated: 30/Aug/11  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Behaviors, I18n
Affects Version/s: 1.2.0
Fix Version/s: 1.2.2

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

Attachments: Text File I18n.patch    

 Description   

I need to override the LANG column size on i18n tables, so I can use "pt_BR" language. I'd like the LANG column to be varchar(5) and not char(5) as it happens if I modify the field length to 5.

I've also tried to set the "fixed" option as false, but I noticed that the I18n generator overrides this option (I18n.php - line 98).

The only workaround I could find was setting the length option as null and the type as varchar(5), but at least for me, it doesn't seem to be the most correct way to define it.

I'd suggest modifying the I18n table definition generator to not override this option.

I've attached a patch with the proposed fix.



 Comments   
Comment by Gilmar Pupo [ 14/Sep/10 ]

I confirm the problem by using en_US.
I ended up using a modified trunk of lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/I18n.php

Comment by Gilmar Pupo [ 30/Aug/11 ]

SImple fix:

— a/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/I18n.php
+++ b/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/I18n.php
@@ -42,7 +42,7 @@ class Doctrine_I18n extends Doctrine_Record_Generator
'children' => array(),
'i18nField' => 'lang',
'type' => 'string',

  • 'length' => 2,
    + 'length' => 5,
    'options' => array(),
    'cascadeDelete' => true,
    'appLevelDelete'=> false
    @@ -131,4 +131,4 @@ class Doctrine_I18n extends Doctrine_Record_Generator
    }
    }
    }
    -}




[DC-419] Sluggable and inheritance Created: 11/Jan/10  Updated: 06/Sep/11  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Behaviors
Affects Version/s: 1.2.0
Fix Version/s: 1.2.2

Type: Bug Priority: Major
Reporter: Pierre B Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 2
Labels: None
Environment:

Symfony 1.4.1 LAMP


Attachments: Text File sluggable.patch    

 Description   

I've the same problem than this post : http://groups.google.com/group/doctrine-user/browse_thread/thread/3737fd293fef5fda/d86a8bc2578e4bac

Then, I've set "uniqueBy: [name, type] ", and my data goes in database BUT they can have the same slug.

So I can't retrieve an objects wich has equal slug with another.

The column aggregation inheritance does'nt take care of others slugs.



 Comments   
Comment by Jan Míšek [ 01/Mar/10 ]

First, inheritance is great feature, thanks doctrine team.

But I have this problem too.

I have identified, the problem is related to class: "Doctrine_Template_Listener_Sluggable", to method: getUniqueSlug($record, $slugFromFields). In mentioned method, table is retrieved from $record ($record->getTable()), but record could be inherited class, so query result on the table is limited only to records of the inherited class. But there could be already rows of other inherited classes with same slug in the database.

Fast hack to solve it, works for me:

  • Added option variable to behaviour "table"
  • Replaced all calls $record->getTable() as Doctrine::getTable($this->_options['table'])
Comment by Ivar Nesje [ 02/Mar/10 ]

Thanks for the solution. I do not like the idea of patching the core framework, but it's just how we will have to deal with it. I hope someone will comment on this bugreport so that I'll be informed when the issue is fixed.

The point of sluggable with column aggregation inheritance is to have a unique identifier to make a common interface for all entitis. Like /events/:slug where the presentation is dependent on the modell.
Ofcourse I could have set up one route for every child class, but that will make more code for configuration, whitch is a pain to maintain.

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

Can anyone provide a patch for the change so I can see everything clearly? Thanks, Jon

Comment by Ivar Nesje [ 03/Mar/10 ]

Here is a simple patch implementing the changes Jan Míšek proposed. (as far as I understod them)

To make the solution better, it would be nice if the Behaviour somhow found out that it was a child class (without requirering me to specify the parent ) and made sure that it made a slug unique across all subclases, unless the unique by setting spesified the type column. I'm realy glad I had a lot of data to import from a previous site, so that I discovered this bug. I use column aggregation inheritance to make the code for presenting different events in a different way simple. But every event sholud be accessable trough the same route mysite.com/events/:slug.

Comment by Ivar Nesje [ 03/Mar/10 ]

I hope this patch and test cases solves more than my problems.

Comment by Ivar Nesje [ 04/Mar/10 ]

Updated the patch a little, so that it does not try to instanciate an abstract class as doctrine generates them.

I was walking up the inheritance tree and tried to instanciate the class right under DoctrineRecord unfortunatly in symfony there is many layers of abstract classes before you find the base class. Now the plugin walks back to the highes not abstract class

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

Thanks for the issue and patch.

Comment by Klemens Ullmann-Marx [ 09/Apr/10 ]

This fix breaks my system.

@see: http://groups.google.com/group/doctrine-dev/browse_thread/thread/8028e51d5bde27eb

Comment by Ivar Nesje [ 09/Apr/10 ]

Hmm.. I'm sory that my ugly fix to remove the 'where type = $type' part of the query to find existing slugs that might cause a colission with the proposed slug.

Does anyone have a better idea on how to ask for all slugs in the same model? I had a pretty hard time traversing the inheritance tree to find the right parent class that were not abstract. I see that something similar has been done about soft delete, so that a new record would not get the same slug as a record marked as deleted, but not removed from the databse.

Comment by Klemens Ullmann-Marx [ 06/Sep/11 ]

Here's an improved patch with a better algorithm to find the column aggregation inhertiance base class:

http://trac.ullright.org/browser/trunk/plugins/ullCorePlugin/patch/Sluggable.patch?rev=3067

This fixes my problem (see above)





[DC-414] Sluggable template fails on case insensitive fields [solution] Created: 10/Jan/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.0.12, 1.0.13, 1.0.14, 1.1.4, 1.1.5, 1.1.6, 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
Fix Version/s: 1.2.2

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


 Description   

Doctrine_Template_Listener_Sluggable performs the following check to see if an existing matching slug exists (line 219):

Sluggable.php
while (in_array($slug, $similarSlugs)) {
  $slug = call_user_func_array($this->_options['builder'], array($proposal.'-'.$i, $record));
  $i++;
}

in_array performs case sensitive string matching, which can cause errors if the sluggable field is case insensitive. This can easily be fixed by calling strtolower when creating the $similarSlugs array and on $slug itself. That is:

Sluggable.php
$similarSlugs = array();
foreach ($similarSlugResult as $key => $value) {
    $similarSlugs[$key] = strtolower($value[$name]);
}

$i = 1;
while (in_array(strtolower($slug), $similarSlugs)) {
    $slug = call_user_func_array($this->_options['builder'], array($proposal.'-'.$i, $record));
    $i++;
}

Even if the sluggable column is BINARY / case sensitive, I think it's an undesired behavior to have multiple slugs with the same case insensitive string.



 Comments   
Comment by Jeremy Kauffman [ 10/Jan/10 ]

Messed up the formatting.

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

I don't see how this change is necessary. The generated slugs are always lowercases anyways. These strtolower() functions don't do anything.

Comment by Jeremy Kauffman [ 01/Mar/10 ]

Jon,

The resulting slugs are only in lower case if you are using the default slug builder (Doctrine_Inflector::urlize). I didn't realize that urlize made called str_to_lower or I would have mentioned that.

So, this is still a bug. In MySQL, unique indexes are case insensitive*. in_array performs case sensitive comparisons. So if I have a slug builder that allows variations in case, it is possible for Sluggable to generate two identical slugs.

To reproduce this bug, comment out the "strtolower"/"mb_strttolower" functions in Inflector::urlize and save a record with two identical fields that are used to generate a slug.

*is this the SQL standard? I did a search but couldn't find an answer)





[DC-413] Validating Spanish Ñ produces "Notice" Created: 10/Jan/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

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

Windows 7, WAMP Server, PHP 5.2.6



 Description   

Doctrine Version 1.2.1

I am entering a simple string into a text input, and running a validator for non-blank and minimum length.

When I enter a Spanish character such as Ñ (N with squiggle on top), the Validator is producing a notice:

Notice: iconv_strlen() [function.iconv-strlen]: Detected an incomplete multibyte character in input string in D:\wamp\www\doctrine\lib\Doctrine\Validator.php on line 131

One work-around suggested at http://www.php.net/manual/en/function.iconv-strlen.php#62320 is to use
return strlen(utf8_decode($string));
instead - not sure whether that provides the same result, though. I have replaced the line in my own Validator class and it seems to be working fine.






[DC-411] Doctrine::Inflector does not handle table names with dashes Created: 08/Jan/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

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


 Description   

I have some tables in my DB with dashes in name, ex. "table-name".
While generating schema.yml with ./doctrine-cli generate-yaml-db it generated model classes with dashes, ex. class Table-name ...

Here's a small patch to treat - in table names same as _.

— library/Doctrine/Inflector.php (wersja 7016)
+++ library/Doctrine/Inflector.php (kopia robocza)
@@ -57,7 +57,7 @@
public static function classify($word)

{ $word = preg_replace('/[$]/', '', $word); - return preg_replace_callback('~(_?)(_)([\w])~', array("Doctrine_Inflector", "classifyCallback"), ucfirst(strtolower($word))); + return preg_replace_callback('~(_?)([-_])([\w])~', array("Doctrine_Inflector", "classifyCallback"), ucfirst(strtolower($word))); }

/**



 Comments   
Comment by Tomasz Sterna [ 08/Jan/10 ]

linebreaks got lost.
basically (_)([\w]) turns to ([-_])([\w])





[DC-410] Email-validator doesn't work Created: 08/Jan/10  Updated: 02/Mar/10  Resolved: 02/Mar/10

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

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

PostgreSQL 8.4, PHP 5.2.11, Apache2


Attachments: File BaseAppUser.php     File schema.yml    

 Description   

I'm generating my models from YAML. The email validator is correctly parsed into the model, but it doesn't work. If I try to insert 'a' or something that is not valid, I don't get any error at all and the row is inserted. See attachments for models.

$user = new AppUser();
$user->name = 'Testuser';
$user->password = sha1('lala');
$user->email = 'a';
$user->role = 'ADMIN';
$user->save();



 Comments   
Comment by Benjamin Steininger [ 17/Jan/10 ]

Is Validation activated for your Connection/Manager via the attributes ? It's off by default.

From the manual:
http://www.doctrine-project.org/documentation/manual/1_2/en/configuration#naming-convention-attributes:validation-mode-constants

Validation by default is turned off so if you wish for your data to be validated you will need to enable it. Some examples of how to change this configuration are provided below.

Comment by Sander [ 17/Jan/10 ]

Ah crap, I feel so stupid. My bad......





[DC-408] Schema generation on Oracle databases fails due to invalid/unexistant table names Created: 08/Jan/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Schema Files
Affects Version/s: 1.2.0
Fix Version/s: 1.2.2

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

PHP 5.2.4-2ubuntu5.9 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 26 2009 14:00:44)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

Oracle database 10gR2
Symfony 1.4.1



 Description   

Sometimes the ORACLE engine has object names that are not tables, and the doctrine generator tries to
generate classes for them, the following patch solves the problem.

[Solution found thanks to Vladimir Tamara - vtamara AT pasosdejesus DOT org]

diff -u Doctrine/Import/Oracle.php.orig Doctrine/Import/Oracle.php

--- Doctrine/Import/Oracle.php.orig     2010-01-07 17:08:33.000000000
-0500
+++ Doctrine/Import/Oracle.php  2010-01-07 17:08:54.000000000 -0500
@@ -203,7 +203,7 @@
      */
     public function listTables($database = null)
     {
-        $query = "SELECT * FROM user_objects WHERE object_type =
'TABLE'";
+        $query = "SELECT * FROM user_objects WHERE object_type =
'TABLE' and object_name in (select table_name from user_tables)";
         return $this->conn->fetchColumn($query);
     }

@@ -252,4 +252,4 @@
         $query = 'SELECT view_name FROM sys.user_views';
         return $this->conn->fetchColumn($query);
     }
-}
\ No newline at end of file
+}


 Comments   
Comment by Miloslav "adrive" Kmet [ 31/Jan/10 ]

Hi Andres.

Bear in mind, that materialized views are also acting like a table. But I think, that they should be imported into doctrine's models too. But I never use an schema Import.

I don't see any differences in the results of both queries.

{{
SELECT * FROM user_objects WHERE object_type = 'TABLE';
SELECT * FROM user_objects WHERE object_type = 'TABLE' and object_name in (select table_name from user_tables)
}}

Both are returning the same resultset. I have only basic objects (tables, views, mviews, some synonyms and some database links). No custom types and so on...

Wouldn't be much better to use only "select table_name from user_tables" ?

I am curious what object types are also acted like a table except mviews. Can you provide more info about your database objects?

Comment by Andres Molina [ 31/Jan/10 ]

Miloslav,

The issue I was having was that Oracle was generating some sort of mirror images of existing tables and saving them as table objects with very funky names (names that Doctrine wasn't able to parse correctly). The query modification I supplied makes sure that the tables objects found by the original query are also the tables named in user_tables, and not the aforementioned "mirror images".

It would in fact be simpler to use "select table_name from user_tables", but I wasn't sure whether object information was used somewhere else.

The database I was using was pretty simple. Pretty much your run-of-the-mill relational tables and a couple of sequences. I wasn't using any views or anything of the sort.

As far as I can tell, the user objects that were causing a problem were some sort of temporary objects Oracle creates and stores as table objects.

Comment by Miloslav "adrive" Kmet [ 31/Jan/10 ]

That sounds like dropped objects in recycle bin. They usually have funky names with all the bells and whistles around alphanumerical keys (eg:"BIN$HGnc55/7rRPgQPeM/qQoRw==$0") .

Just purge your recycle bin with "purge recyclebin;".

Comment by Andres Molina [ 03/Feb/10 ]

Unfortunately, the database that was giving me issues no longer exists, so I can't test if "purge recyclebin". However, the example object_name you gave is spot-on, so I'm pretty sure that's the cause of the issue.

Either way, I think the modification to the query I submitted is worthwhile as it would avoid this type of issue. If no data from objects is necessary, the query could be replaced altogether with "select table_name from user_tables" (as Miloslav mentioned in the first comment).





[DC-407] Doctrine_Core::HYDRATE_SINGLE_SCALAR improvement Created: 08/Jan/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Improvement Priority: Minor
Reporter: Reko Tiira Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 2
Labels: None

Attachments: Text File Doctrine_Hydrate_SingleScalar.patch    

 Description   

Right now HYDRATE_SINGLE_SCALAR will always return one value, regardless of whether you use execute() or fetchOne(). This limits the usefulness of the hydrator, as it could be expanded to work in situations where you want to hydrate a single column from a result-set. For example think of a scenario where you want to populate a multi option element of a form with IDs from a db model.

Right now if you have this:

$items = Doctrine_Query::create()->select('id')->from('Items')->execute(array(), Doctrine_Core::HYDRATE_SINGLE_SCALAR);

You will end up having just the id of the first item. However I think it should return a flat array of all the ids, like this:

array(1, 3, 4, 5, 8)

Having it work this way would still let you use HYDRATE_SINGLE_SCALAR to hydrate a single value; you would just use fetchOne instead of execute. Changing the implementation won't really have any negative performance impacts either.

I've attached a patch that adds this functionality and updates the unit tests to take it into account.

I realize that this might not be added in 1.2 since it'd break backwards compatibility, but if there's going to be 1.3, this should be in it.



 Comments   
Comment by Lukas Kahwe [ 13/Jan/10 ]

i agree .. there is a lot of power in PDO's fetchAll() also in terms of grouping (PDO::FETCH_GROUP, PDO::FETCH_UNIQUE) data etc. that is hidden in Doctrine. i have even found myself having to fallback to PDO in a few places because of this.

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

We can't change this in Doctrine 1.2 as it would break BC.

Comment by Lukas Kahwe [ 02/Mar/10 ]

yeah obviously there would be a need for new fetch modes. but this means new features, risking new bugs etc.

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

Hi, I modified your patch a bit and committed it. I think this should be ok now and is backwards compatible with the previous version.





[DC-406] more robust handling for "actAs: [Timstampable]" handling Created: 07/Jan/10  Updated: 12/Jan/10  Resolved: 12/Jan/10

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

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

Attachments: File Builder.php.diff    

 Description   

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

This patch ensures that any numeric keys are flipped individually instead of simply peaking into the first element and assuming the rest of the array has the same structure.






[DC-404] Allow custom language field name in I18n Behavior Created: 07/Jan/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

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

Attachments: File i18n_configurable_field.diff    

 Description   

I18n behavior assumes language field name of 'lang'. It would be nice if this was configurable.

This was mentioned and a proposed solution was given here: http://forum.symfony-project.org/index.php/m/85623/

I've attached a patch which implements this solution, it essentially adds an i18nField option to the behaviour. The field defaults to 'lang'.

The patch was made against r7016 of the 1.2 branch.

Note:

  • Leaving the field name as 'lang' does not cause unit test failures.
  • Changing the name of the field does cause some unit tests to fail for me. I'm not sure if the dependency on the field name exists in the unit tests or in the doctrine library itself. If dependencies exist in the library, this patch may not be sufficient to add the feature.

Sorry if the patch is incomplete, I'm new to Doctrine in general.






[DC-398] PORTABILITY_EMPTY_TO_NULL doesn't do anything for statements Created: 05/Jan/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Connection
Affects Version/s: 1.0.14, 1.1.6, 1.2.1
Fix Version/s: 1.2.2

Type: Bug Priority: Major
Reporter: Thomas Albright Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 1
Labels: None

Attachments: File patch.diff    

 Description   

I found this ticket on the old Trac system, but not on JIRA. It is still broken in the 1.1 branch, as of revision 7004. It is also broken in 1.0.14, 1.1.6, and 1.2.1. (These were the 'stable' releases at the time I reported this bug.) It is likely broken in older releases as well.

When saving to the database, Doctrine ignores the setting of PORTABILITY_EMPTY_TO_NULL. Currently, it will never change empty strings to NULL, no matter what the setting is for ATRR_PORTABILITY. This is because there is an error in the following 'if' statement:

Doctrine_Connection_Statement starting on line: 234

if ($this->_conn->getAttribute(Doctrine::PORTABILITY_EMPTY_TO_NULL)) {
    foreach ($params as $key => $value) {
        if ($value == '') {
            $params[$key] = null;
        }
    }
}

the first test in this block should be (Portability Mode Attributes must be handled this way):

if ($this->_conn->getAttribute(Doctrine::ATTR_PORTABILITY) & Doctrine::PORTABILITY_EMPTY_TO_NULL) {

the second test should be:

if (is_string($value) && $value === '')

In newer versions of php(not sure which), test for empty string must look like '===' not only '=='. It prevents integer and boolean value 0 to be handled as an empty string.



 Comments   
Comment by Dorian [ 08/Jan/10 ]

It's the same problem with.

$oDCon->setAttribute(Doctrine::ATTR_PORTABILITY, Doctrine::PORTABILITY_RTRIM);

I think Doctrine::ATTR_ don't work.

Comment by Erin Millard [ 12/Jan/10 ]

It would be really great to see this issue fixed. As for the suggested changes above, I believe the === operator checks against type also, and therefore the is_string() call is redundant.

Comment by Thomas Albright [ 22/Feb/10 ]

Here is a patch for 1.2.1.





[DC-397] unlinking of associations with aliased local-/foreignKeys is broken Created: 05/Jan/10  Updated: 02/Mar/10  Resolved: 02/Mar/10

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

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

Attachments: File patch_DC-397.diff    

 Description   

Doctrine_Connection_UnitOfWork->saveAssociations() does not use column-aliases for database-columns but only field-names. The following patch deals with this problem:

Index: lib/Doctrine/Connection/UnitOfWork.php
===================================================================
— lib/Doctrine/Connection/UnitOfWork.php (revision 7004)
+++ lib/Doctrine/Connection/UnitOfWork.php (working copy)
@@ -439,8 +439,8 @@
$assocTable = $rel->getAssociationTable();
foreach ($v->getDeleteDiff() as $r)

{ $query = 'DELETE FROM ' . $assocTable->getTableName() - . ' WHERE ' . $rel->getForeign() . ' = ?' - . ' AND ' . $rel->getLocal() . ' = ?'; + . ' WHERE ' . $rel->getForeignRefColumnName() . ' = ?' + . ' AND ' . $rel->getLocalRefColumnName() . ' = ?'; $this->conn->execute($query, array($r->getIncremented(), $record->getIncremented())); }




[DC-395] sfYaml library included twice Created: 05/Jan/10  Updated: 08/Jun/10  Resolved: 08/Jun/10

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

Type: Bug Priority: Major
Reporter: Karma Dordrak (Drak) Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

I don't know if this is important but it seems sfYaml is included twice in Doctrine 1.2.1. Once in vendor/sfYaml and once again in Doctrine/Parser/sfYaml



 Comments   
Comment by Benjamin Eberlei [ 16/Feb/10 ]

This should be fixed asap, it makes running the test-suite (with coverage) impossible.





[DC-394] Searchable behavior's batchUpdateIndex fails if a table has a composite primary key. Created: 04/Jan/10  Updated: 02/Mar/10  Resolved: 02/Mar/10

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

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

Attachments: Text File Doctrine_Search.patch    

 Description   

You will get the following error when you try to batchUpdateIndex a table with composite key:

Fatal error: Uncaught exception 'ErrorException' with message 'strpos() expects parameter 1 to be string, array given' in library/Doctrine/Connection.php:725

Here's the full stack trace:

Stack trace:
#0 [internal function]: Bootstrap->errorHandler(2, 'strpos() expect...', '/Users/reko/Sit...', 725, Array)
#1 /Users/reko/Sites/MyProject/library/Doctrine/Connection.php(725): strpos(Array, '.')
#2 /Users/reko/Sites/MyProject/library/Doctrine/Search.php(246): Doctrine_Connection->quoteIdentifier(Array)
#3 /Users/reko/Sites/MyProject/library/Doctrine/Template/Searchable.php(69): Doctrine_Search->batchUpdateIndex(NULL, NULL, NULL)
#4 /Users/reko/Sites/MyProject/library/Doctrine/Template/Searchable.php(81): Doctrine_Template_Searchable->batchUpdateIndex(NULL, NULL, NULL)
#5 [internal function]: Doctrine_Template_Searchable->batchUpdateIndexTableProxy()
#6 /Users/reko/Sites/MyProject/library/Doctrine/Record.php(2622): call_user_func_array(Array, Array)
#7 [internal function]: Doctrine_Record->__call('batchUpdateInde...', Array)
#8 [internal function]: In in /Users/reko/Sites/MyProject/library/Doctrine/Connection.php on line 725

I know that it's recommended that you don't use composite primary keys, but this happens to occur when you stack the I18n and Searchable behaviour together, since the Translation table I18n behavior creates uses a composite key on (id, lang).

Anyways, the bug was quite simple one to fix and I've attached a patch that fixes the issue.






[DC-385] Behavior geographical generates latitude FLOAT(18, 2), longitude FLOAT(18, 2) - it's not exact Created: 24/Dec/09  Updated: 11/Aug/11  Resolved: 01/Mar/10

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

Type: Bug Priority: Major
Reporter: Dominik.Roser Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 2
Labels: None
Environment:

symfony 1.4.1 / mysql



 Description   

The problem was already described by another person at http://trac.symfony-project.org/ticket/7763
the generated field-type is wrong, so the stored lat/long values have lost precision.



 Comments   
Comment by Hash [ 03/Mar/10 ]

This change doesn't fix the problem. The problem here is that float and double types default to (18,2) for no good reason. See line 233: http://trac.doctrine-project.org/browser/branches/1.2/lib/Doctrine/DataDict/Mysql.php?rev=7253

I think u need to let the default mysql float and double types be set if options are not specified explicitly for length/scale. This problem causes all doubles and floats to have poor 2 decimal precision.

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

Doctrine always sets the default if nothing is specified currently so we can't change that we can set our own length and scale though. However, I don't know what proper values would be. I'll do some tests and report back, let me know if you have any additional information. Thanks, Jon

Comment by Hash [ 23/Apr/10 ]

Well it seems that Doctrine sets the default to 18,2 but afaik that is not necessary. I would suggest that if no scale is specified then the data type is simply defined as FLOAT or DOUBLE with no scale. This works fine for Mysql in my project.

Comment by Severin Puschkarski [ 13/Oct/10 ]

On Symfony 1.4.8 / Mysql it is still not working
Setting to
type: float(18), scale: 6
enhances precission, but the numbers are rounded weirdly in the database:
for example 76.86 is stored as 76.860001
I really would appreciate a true mysql float!!!

Comment by Malcolm Hall [ 11/Aug/11 ]

Still broken on 1.2.4 the last release of 1.2 unfortunately. This is the fix I used:

Change line 239 of lib/Doctrine/DataDict/Mysql.php from:

return 'DOUBLE('.$length.', '.$scale.')';

to

return 'DOUBLE';

This gets rid of scale completely but I think its better than all doubles that don't have a defined scale limited to decimal places, which is just awful for anyone using the Geographical behaviour.





[DC-384] Nested set API allows inconsistent trees to be created Created: 23/Dec/09  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Symfony 1.4


Attachments: File nest.tgz     Text File no-move-into-descendant.patch    

 Description   

First create a tree as follows:

A
B
C
D

That is, C and D are both children of B, and B is a child of A.

At this point our db looks as follows:

mysql> select SLUG, LFT, RGT, LEVEL from pk_context_cms_page;
-----------------------+

SLUG LFT RGT LEVEL

-----------------------+

/ 1 12 0
/about 10 11 1
global NULL NULL NULL
/a 2 9 1
/a/b 3 8 2
/a/b/c 4 5 3
/a/b/c/d 6 7 3

-----------------------+
7 rows in set (0.00 sec)

Now, call D->moveAsLastChildOf(C). D is now a child of C.

So far so good:

mysql> select SLUG, LFT, RGT, LEVEL from pk_context_cms_page;
-----------------------+

SLUG LFT RGT LEVEL

-----------------------+

/ 1 12 0
/about 10 11 1
global NULL NULL NULL
/a 2 9 1
/a/b 3 8 2
/a/b/c 4 7 3
/a/b/c/d 5 6 4

-----------------------+
7 rows in set (0.00 sec)

Now, call C->moveAsLastChildOf(D). This should pull D out from under C.

Instead the values of LFT and RGT get messed up:

mysql> select SLUG, LFT, RGT, LEVEL from pk_context_cms_page
-> ;
-----------------------+

SLUG LFT RGT LEVEL

-----------------------+

/ 1 12 0
/about 10 11 1
global NULL NULL NULL
/a 2 9 1
/a/b 3 8 2
/a/b/c 6 7 5
/a/b/c/d 7 6 4

-----------------------+
7 rows in set (0.00 sec)

moveAsLastChildOf should either (1) implement moving ancestors beneath their children correctly or (2) refuse to do so.

Note: these actions were carried out as separate PHP requests.

This is easy to reproduce by firing up the Apostrophe sandbox project, logging in as admin/admin, creating the page structure described, and then clicking the apostrophe in the upper left and then the Reorganize tool.

Instructions to check out the current sandbox are here:

http://www.apostrophenow.com/home/readme

You'll need to set up databases.yml and do a build --all and a data-load, that's about it.

Be sure to open a second tab so that you can have two views of the tree showing the initial state (C and D both as kids of B) so that you can drag D under C in the first tab and then try to drag C under D in the second tab. Otherwise the tree editor itself will block you from trying to move C under D.

The implementation of pkContextCMS/executeTreeMove is calling moveAsLastChildOf() in both cases and doing so to the right pages. I've added logging to verify this, look for references to TREEMOVE in the frontend_log.dev file.

We are going to add checks at the pkContextCMS level to refuse to attempt to move an ancestor beneath one of its children as a workaround, although in principle that should be possible (at least if the ancestor has no children? Not sure if it always makes sense if it does have children other than the ancestors of the new parent).



 Comments   
Comment by Dan Ordille [ 23/Dec/09 ]

I have attached a symfony project to demonstrate the problem. Project is using latest symfony version form 1.4 svn. Run test located in test/unit/corrupt.php

The test creates 3 nodes A, B, and C.
Inserts B as last child of a.
Inserts C as last child of a.
The nodes then have the following properties.

Node lft rgt lvl
A 1 6 0
B 2 3 1
C 5 5 1

A is then moved as the first child of B which causes corrupted nested sets.

Node lft rgt lvl
A 3 6 2
B 4 3 1
C 4 5 1

A is still the parent of B and C, yet its level is 2.

This problem exists whenever a node is moved into one of its children or descendants.

Comment by Dan Ordille [ 23/Dec/09 ]

I created a patch that prevents moving a node into its descendants.

I was trying to think what the ideal behavior would be in this situation, but at least this patch will prevent corruption.

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

Thanks for the issue Tom and patch Dan. Let me know if we still have any issues remaining.





[DC-381] Automatic sequence names - with patch Created: 23/Dec/09  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

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

Attachments: Text File schema_sequence.patch    

 Description   

Right now in yaml schema if you write sequence: true all the sequence names are set to 1.
This fixes the class generator in such way that the table name is used for sequence name if sequence === true otherwise it works just like before.






[DC-380] Sequence SQL is not generated when exporing sql for postgres - with patch Created: 23/Dec/09  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

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

Attachments: Text File pgsql_sql_sequence.patch    

 Description   

I spent a couple of hours on Saturday debugging why the heck the sql for sequences doesn't get generated for Postgresql. As it seems somebody forget about that when writing the export driver.

Attached is a patch against 1.2.1 version.
This probably also applies to Doctrine 2!



 Comments   
Comment by Jonathan H. Wage [ 01/Mar/10 ]

Thanks for the issue and patch.





[DC-378] Typo in documentation for Taggable Extension Created: 22/Dec/09  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Bug Priority: Minor
Reporter: Fabien Pennequin Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 1
Labels: None

Attachments: Text File DocsGetPopularTags.patch    

 Description   

There are some typos in your documentation for Taggable extension.

In section related to getPopularTags method, if I use your code, like Doctrine::getTable('BlogPost')->getPopularTags(); I get an exception "Unknown method Doctrine_Table::getPopularTags" (with replacing BlogPost by my model name). In effect, it's not the table for my model that I must use but the table for TaggeableTag.
Besides, in your tests, you use Doctrine::getTable('TaggableTag')

I have write a patch to fix these typos. It's attached to this ticket.



 Comments   
Comment by Benjamin Arthur Lupton [ 02/Mar/10 ]

I believe the TaggableTag table is used to hold all tags, so if you have multiple tables that use tags, TaggableTag will contain the tags for all the tables using the Taggable extension. By doing: Doctrine::getTable('BlogPost')->getPopularTags(); we only want to get the popular tags for that table alone.

However, I could be totally wrong???

Comment by Ivar Nesje [ 03/Mar/10 ]

Only problem is that I can not Doctrine::getTable('BogPost')->getPopularTags() throws an exeption.
You wil have to do as in the test case and make sure that the table clases is loaded.

// Load the models you want tags form
Doctrine::getTable('BlogPost');
Doctrine::getTable('Article');
// Then the automaticaly generated TaggableTag model can be loaded
$tags = Doctrine::getTable('TaggableTag')->getPopularTags();
// or you can spesify spesific models you want tags from
$tags = Doctrine::getTable('TaggableTag')->getPopularTags(array('BlogPost','Article'));

This is how it works for me, at least. Benjamin, have you tested and got a resonable result from Doctrine::getTable('BlogPost')->getPopularTags()?





[DC-377] Cannot delete a taggable record (Taggable Extension) Created: 22/Dec/09  Updated: 10/Aug/12  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Extensions
Affects Version/s: 1.2.0, 1.2.1
Fix Version/s: 1.2.2

Type: Bug Priority: Major
Reporter: Fabien Pennequin Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 1
Labels: None
Environment:

PHP 5.3.1, Mac OS X (10.6), MySQL 5.0.86, Symfony 1.4.1


Attachments: Text File TaggableConstraintError.patch    

 Description   

With Taggable extension, when I try to delete a record using Taggable, I get this exception :

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`sf_sandbox/article_taggable_tag`, CONSTRAINT `article_taggable_tag_id_article_id` FOREIGN KEY (`id`) REFERENCES `article` (`id`))

If I check the sql queries generated by Doctrine, there are not "onDelete CASCADE" for one of relation added by Taggable extension.

I have write some test cases for reproduce this bug (checking if relation has a property onDelete setted to CASCADE) but I can't reproduce the thrown exception in test case because sqlite omits queries with constraint. Also, I found how to fix this bug.

The fix and test cases are available in the file attached to this ticket.



 Comments   
Comment by Jason [ 20/Apr/10 ]

Hi Jon-

Where can I find this fix?

http://svn.doctrine-project.org/extensions/Taggable/branches/1.2-1.0 (the link referenced from the docs at http://www.doctrine-project.org/extension/Taggable) doesn't have this fix.

Comment by Jason [ 20/Apr/10 ]

Sorry, it appears the patch attached above is in SVN, however this is still broken.

With Doctrine 1.2.2 sandbox configured to work with MySQL 5.x database on 5.2.10, using the following schema

{{
BlogPost:
actAs: [Taggable]
columns:
title:
type: string(255)
notnull: true
description:
type: string(255)
notnull: true
}}

the CASCADE in the constraints for the table being applied the Taggable behavior are still not being applied (see first constraint below)

{{
CREATE TABLE `blog_post_taggable_tag` (
`id` bigint(20) NOT NULL DEFAULT '0',
`tag_id` bigint(20) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`,`tag_id`),
KEY `blog_post_taggable_tag_tag_id_taggable_tag_id` (`tag_id`),
CONSTRAINT `blog_post_taggable_tag_id_blog_post_id` FOREIGN KEY (`id`) REFERENCES `blog_post` (`id`),
CONSTRAINT `blog_post_taggable_tag_tag_id_taggable_tag_id` FOREIGN KEY (`tag_id`) REFERENCES `taggable_tag` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
}}

Comment by Malcolm Hall [ 10/Aug/12 ]

I use Doctrine v1.2.4 and created a fix for this problem, change the _options array initialization in Taggable.php to this:

protected $_options = array(
'builderOptions' => array(),
'tagField' => null,
'cascadeDelete' => true
);

This works because parent::buildRelation() calls the buildLocalRelation() method in Generator.php which looks for the cascadeDelete and if true then it adds the necessary CASCADE params, as you can see below:

public function buildLocalRelation($alias = null)
{
...
if (isset($this->_options['cascadeDelete']) && $this->_options['cascadeDelete'] && ! $this->_options['appLevelDelete'])

{ $options['onDelete'] = 'CASCADE'; $options['onUpdate'] = 'CASCADE'; }

...

Now both parts of the taggable relation get the cascade on delete feature. So if you delete a tag OR you delete a post, the row in the taggable_tag table gets deleted too.





[DC-374] importing sqlite db with doctrine does not detect autoincrement fields Created: 21/Dec/09  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: 1.2.2

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

sqlite3


Attachments: Text File sqlite-autoincrement.patch    

 Description   

when importing a sqlite db with doctrine it fails to detect autoincrement fields resulting in exceptions when inserting records, like this one:
Uncaught exception 'Doctrine_Connection_Sqlite_Exception' with message 'SQLSTATE[23000]: Integrity constraint violation: 19 usergroup.group_id may not be NULL' in /Users/aiso/dev/php/cms/mix/lib/ext/doctrine/Doctrine/Connection.php:1083.

This is caused by the fact that there is no check on 'autoincrement' in Import/Sqlite.php. In sqlite3 a field is autoincrement whenever its type is integer and is a primary key.

a patch is included.






[DC-366] Error with tokenizer for JOINs (comments include proposed solutions) Created: 18/Dec/09  Updated: 02/Mar/10  Resolved: 02/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.2.0
Fix Version/s: 1.2.2

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

Symfony-1.3, reporting below is based on the symfony-1.3.1 sandbox, but same problem occurs in other (non-sandbox) symfony-1.3 environments


Attachments: Text File jira-ticket-dc366.patch     File schema.yml    

 Description   

Using the attached schema.yml works fine with Symfony-1.2 and Doctrine-1.0. It even works when I have tested it with Symfony-1.2 and Doctrine-1.1.

However, when using Symfony-1.3 and Doctrine-1.2 the following happens:

 
> php symfony doctrine:build-all-reload
>> doctrine  Dropping "doctrine" database
>> doctrine  Creating "dev" environment "doctrine" database
>> doctrine  generating model classes
>> file+     C:\Users\XXXXXXXXXXXXXXXX\AppDa...\Temp/doctrine_schema_30398.yml
>> tokens    C:/web/sf_sandbox-1.3/lib/model/doctrine/base/BaseBar.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/model/doctrine/base/BaseFoo.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/model...e/base/BaseJoinFooBar.class.php
>> autoload  Resetting application autoloaders
>> file-     C:/web/sf_sandbox-1.3/cache/fro.../config/config_autoload.yml.php
>> doctrine  generating form classes
>> tokens    C:/web/sf_sandbox-1.3/lib/form/BaseForm.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/form/doctrine/BarForm.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/form/...rine/base/BaseBarForm.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/form/...rine/base/BaseFooForm.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/form/...se/BaseJoinFooBarForm.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/form/...rine/BaseFormDoctrine.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/form/doctrine/FooForm.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/form/doctrine/JoinFooBarForm.class.php
>> autoload  Resetting application autoloaders
>> file-     C:/web/sf_sandbox-1.3/cache/fro.../config/config_autoload.yml.php
>> doctrine  generating filter form classes
>> tokens    C:/web/sf_sandbox-1.3/lib/filte...octrine/BarFormFilter.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/filte...ase/BaseBarFormFilter.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/filte...ase/BaseFooFormFilter.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/filte...eJoinFooBarFormFilter.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/filte...aseFormFilterDoctrine.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/filte...octrine/FooFormFilter.class.php
>> tokens    C:/web/sf_sandbox-1.3/lib/filte.../JoinFooBarFormFilter.class.php
>> autoload  Resetting application autoloaders
>> file-     C:/web/sf_sandbox-1.3/cache/fro.../config/config_autoload.yml.php
>> doctrine  generating sql for models
>> doctrine  Generated SQL successfully for models
>> doctrine  created tables successfully
>> doctrine  Loading data fixtures from "C:\web\sf_sandbox-1.3\data/fixtures"


  Couldn't find class FooBar

The attached schema.yml looks like this:

# /config/doctrine/schema.yml
Foo:
  columns:
    id:
      type:                    integer(8)
      primary:                 true
      autoincrement:           true
    foo_field:                 string(100)
  relations:
    Bars:
      class:                   Bar
      refClass:                JoinFooBar
      local:                   foo_id
      foreign:                 bar_id
Bar:
  columns:
    id:
      type:                    integer(8)
      primary:                 true
      autoincrement:           true
    bar_field:               string(30)
JoinFooBar:
  columns:
    foo_id:
      type:                    integer(8)
      primary:                 true
    bar_id:
      type:                    integer(8)
      primary:                 true

As you can see, there is not meant to be any class called FooBar (the reference class for the many-to-many join is called JoinFooBar) so where is the name "FooBar" being picked up from and why is the code complaining that it cannot be found?

The fixture file is empty so there shouldn't be anything causing problems there.

This bug is making it impossible to upgrade our existing projects to Symfony-1.3 + Doctrine-1.2 so I'd be most grateful if you could look into this.

If the schema is changed from:

...
    bar_field:               string(30)
JoinFooBar:
  columns:
...

To:

...
    bar_field:               string(30)
FooBar:
  columns:
...

it seems to work, (that error disappears - even though the refClass is still set to *Join*FooBar) but we cannot easily justify changing all the classnames of all our Join tables in the projects we want to upgrade!

I hope you can see some simple solution to this and I'm happy to answer any questions you have.

(To reproduce this bug use the symfony sandbox, create a database and then use the attached schema.yml file.)

C



 Comments   
Comment by Christian Seaman [ 04/Jan/10 ]

As reported here:
http://forum.symfony-project.org/index.php/t/24441/

It seems that the problem is with the doctrine:build-all-reload in symfony and not anything deeper.

As such, I think it would make sense to disactivate that task in symfony (rather than marking it as deprecated) since it is broken and a note in it directing people to use the new tasks would be far more useful.

C

Comment by Christian Seaman [ 04/Jan/10 ]

As noted above, this is not a Critical error with Doctrine, but rather a problem with a symfony task.

Comment by Christian Seaman [ 17/Jan/10 ]

On further inspection, this is not an error with the symfony task, but a problem with the Tokenizer class, in particular where Doctrine_Query_From::parse() calls Doctrine_Query_Tokenizer::bracketExplode() with the delimiter set to 'JOIN'.

Comment by Christian Seaman [ 17/Jan/10 ]

OK... I think I have found and solved this one but a more experienced member of the Doctrine team should review what I propose before adding it to the codebase.

The problem occurs because Doctrine_Query_Tokenizer::getSplitRegExpFromArray() is being passed a string with no word boundaries (the parameter being passed to it by Doctrine_Query_From::parse() is "JOIN"). getSplitRegExpFromArray() then treats this string as a case insensitive regex so if any of your class or field names contain this string they are treated as a split.

E.g. "JoinFooBar JOIN BanjoIndia" would be split into array ("", "FooBar", "Ban", "dia").

This is clearly wrong and would mean that no table or fieldnames could contain the letters j-o-i-n in that order.

The proposed solution is as follows:

Current version of Doctrine_Query_Tokenizer::getSplitRegExpFromArray() (Doctrine 1.2, as of r7034):

 
    private function getSplitRegExpFromArray(array $d){
        $d = array_map('preg_quote', $d);

        if (in_array(' ', $d)) {
            $d[] = '\s';
        }

        return '#(' . implode('|', $d) . ')#';
    }

Proposed modification checks each delimiter given. If that delimiter consists only of \w characters (i.e. [0-9a-zA-Z_]) then a word boundary is required before and after that delimiter if it's going to be used as a match:

 
    private function getSplitRegExpFromArray(array $d){
        foreach ($d as $key => $string) {
            $escapedString = preg_quote($string);
            if (preg_match('#^\w+$#', $string)) $escapedString = "\W$escapedString\W";
            $d[$key] = $escapedString;
        }

        if (in_array(' ', $d)) {
            $d[] = '\s';
        }

        return '#(' . implode('|', $d) . ')#';
    }

Now, this seems to work for me in brief testing for my own purposes. However, the test cases in TokenizerTestCase.php (particularly testBracketExplode()) are far from exhaustive so I'm not sure if this proposed solution would suit all cases. E.g. do you ever need the delimiter to match at the very beginning or end of a string? At the moment it would not match but you could deal with this by using this instead:

 if (preg_match('#^\w+$#', $string)) $escapedString = "(^|\W)$escapedString($|\W)";

An alternative solution, but far less robust, would be just to modify Doctrine_Query_From::parse() from

    public function parse($str, $return = false)
    {
        $str = trim($str);
        $parts = $this->_tokenizer->bracketExplode($str, 'JOIN');

        $from = $return ? array() : null;
...

to this, with spaces around the JOIN string passed to bracketExplode():

    public function parse($str, $return = false)
    {
        $str = trim($str);
        $parts = $this->_tokenizer->bracketExplode($str, ' JOIN ');

        $from = $return ? array() : null;
...

This is probably going to run marginally faster, but it leaves the risk that some change in future will bring up the same problem again, so the former (fixed regexp) solution would seem to be better for stability.

I hope you can pick this up, review it and implement the most suitable change (and update the test cases too) - at the moment this is a big bug since any schema which defines table or fieldnames that contain the consecutive letters j-o-i-n will break.

C

Comment by Matthias Steinböck [ 18/Jan/10 ]

I found the same bug.

The error i got was "Couldn't find class ed". at first i wondered where i used "ed" but i did nowhere. the code i used was:

$from = 'Media';
$alias = 'Content';

$qry = Doctrine_Query::create();
$qry->from("$from orig");
$qry->leftJoin("orig.$alias joined"); // here the error occoures using "joined"

I located the Bug in Doctrine_Query_From using $this->_tokenizer->bracketExplode for checking the right arm of the join so i only can confirm this bug.

Comment by Christian Seaman [ 19/Jan/10 ]

Matthias,

feel free to use the fix detailed above. I have been using this in my local copy of Doctrine and it seems to work well so far.

We just need a member of Doctrine's dev team to decide which of the fixes above makes most sense and then to update the code for the next Doctrine release.

The fix I am using at the moment is the first one:

          if (preg_match('#^\w+$#', $string)) $escapedString = "\W$escapedString\W";
Comment by Jonathan H. Wage [ 01/Mar/10 ]

Hi, before I can test your proposed solution. I need to see a patch with your changes. I can't very easily and reliably copy and paste your changes from the comments.

Comment by Christian Seaman [ 02/Mar/10 ]

Hi Jon,

Thanks for looking into this.

I will generate a patch and attach it to this ticket for your review.

Feel free to rip it apart and change the test cases or regex used.

C

Comment by Christian Seaman [ 02/Mar/10 ]

Patch with suggested fix for the tokenizer and basic test case.





[DC-365] softdelete documentation is outof date Created: 17/Dec/09  Updated: 02/Mar/10  Resolved: 02/Mar/10

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

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


 Description   

out of date http://www.doctrine-project.org/documentation/manual/1_2/en/behaviors#core-behaviors:softdelete the behavior add a deleted_at column from type timestamp






[DC-352] Doctrine_RawSql/Caching fatal error Created: 10/Dec/09  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Resolved
Project: Doctrine 1
Component/s: Caching, Native SQL
Affects Version/s: 1.2.0, 1.2.1
Fix Version/s: 1.2.2

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

Solaris



 Description   

Doctrine_RawSql::calculateResultCacheHash tries to call $this->getSql() - an undefined method - on line 444 of RawSql.php.



 Comments   
Comment by Witold Wasiczko [ 24/Jan/10 ]

I get the same error during:
$q = new Doctrine_RawSql();
$q->useResultCache(true);

I fixed it, by change from:
$sql = $this->getSql();
to:
$sql = $this->getDql();

In Doctrine_RawSql 444 line.





[DC-350] Problem with Doctrine_Record::link() where $this->$alias is NULL (including possible fix) Created: 10/Dec/09  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.1.6
Fix Version/s: 1.2.2

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

symfony 1.2.7
MySQL 5.1.30
php 5.2.8



 Description   

Doctrine 1.1 problem

Doctrine_Record::link() was causing problems for me at the following lines:

 
  foreach ($records as $record) {
    $this->$alias->add($record);
  }

After a little digging, the problem was due to the value of

 $this->$alias

being NULL.

Changing the code to this:

 
  foreach ($records as $record) {
    $this->get($alias)->add($record);
  }

Seemed to solve the problem, but I am not sure if this is the correct thing to do!

Could you take a look at this and then either

  • update this ticket to let me know if this is the right thing to do or
  • patch the next version of doctrine-1.1 to include this fix if this is sensible (and does not break something else!).

For your reference, the code block (in Symfony) that ended up causing a problem here looks something like this:

 
# /lib/model/doctrine/Foo.class.php

class Foo extends BaseFoo {
  public function save(Doctrine_Connection $conn = null) {
    if ($this->isNew()) {
      $this->createBar();
    }
    return parent::save($conn);
  }

 /**
  * Generate a Bar for this Foo and link to it (does NOT save)
  *
  * @return boolean   true if a new Bar was created, false if not
  */
  public function createBar() {
    if (empty($this->sf_guard_user_id)) {
      $this->Bar = new Bar();
      $this->Bar->setAbc($this->getAbc());
      $this->Bar->save();
      $this->Bar->link('xyz', XyzTable::XYZ_ID_DEFAULT); // This is the line that caused the problems
      return true;
    } else {
      return false;
    }
  }
}

Yours,

Christian






[DC-346] synchronize records based on the primary keys, patch available Created: 09/Dec/09  Updated: 11/Mar/10  Resolved: 11/Mar/10

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

Type: Improvement Priority: Major
Reporter: Marcus Häußler Assignee: Jonathan H. Wage
Resolution: Incomplete Votes: 0
Labels: None


 Description   

If I do a synchronizeWithArray(), the order of the elements in the array has to be the same as they are saved in the database.
Of course this can not be assumed in any situation, where you have reordered form-elements etc.

I would expect, if I add the IDs to the elements in the array, that the update-process is based on them and not on the element-order.

Please take a look at this old ticket: http://trac.doctrine-project.org/ticket/2097

The attached patch works really nice on the actual revision too.



 Comments   
Comment by Jonathan H. Wage [ 01/Mar/10 ]

Hi, have you tested this patch against Doctrine 1.2 and ran the test suite? When I give it a try, it wouldn't quite apply cleanly and it seems to break lots of tests. I'll keep looking at it, let me know if you have any more information or if you have another version of the patch. Thanks, Jon





[DC-345] delete reference between OneToOne-Relation with synchronizeWithArray(), patch available Created: 09/Dec/09  Updated: 11/Mar/10  Resolved: 11/Mar/10

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

Type: Improvement Priority: Major
Reporter: Marcus Häußler Assignee: Jonathan H. Wage
Resolution: Incomplete Votes: 0
Labels: None


 Description   

There is no possibility to delete a reference on a OneToOne-Relation with synchronizeWithArray().

If User and Group would be OneToOne related, i would expect that I could do something like the following (like on ManyToMany-Relations), to delete the relation between both.

$user->synchronizeWithArray(array(
    'Group' => array() // no error, but the relation is not deleted
));

or

$user->synchronizeWithArray(array(
    'Group' => array(null) // error, cause doctrine expects an existing ID
));

This fixes the problem:

Index: library/Doctrine/Record.php
===================================================================
--- library/Doctrine/Record.php	(revision 6903)
+++ library/Doctrine/Record.php	(working copy)
@@ -2012,6 +2012,8 @@
                     if (isset($value[0]) && ! is_array($value[0])) {
                         $this->unlink($key, array(), false);
                         $this->link($key, $value, false);
+                    } else if (empty($value) || (null === current($value))) {
+                    	$this->unlink($key, array(), false);
                     } else {
                         $this->$key->synchronizeWithArray($value);
                     }


 Comments   
Comment by Jonathan H. Wage [ 01/Mar/10 ]

Hmm. The second syntax is weird. I think the first syntax makes more sense, no?





[DC-343] Doctrine_View_Exception is documented as "Doctrine_Validator_Exception" Created: 09/Dec/09  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

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


 Description   

PHPdoc mislabels the class






[DC-334] Doctrine_Migration_Diff relies sys_get_tmp_dir in a way that will break with mutliple projects running the command at once Created: 07/Dec/09  Updated: 08/Dec/09  Resolved: 08/Dec/09

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

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

Symfony 1.3



 Description   

sys_get_temp_dir returns the same value at all times for a given Unix user.

This means that if one attempts to run doctrine:generate_migrations_diff on two projects at once, they will contend for the same temporary folder. Temporary files ought to be specific to an instance of a task, or at least to a project.

A fix would be to append getpid() to sys_get_temp_dir and use that as the temp dir throughout the task. That is completely task-specific:

$tmp = sys_get_temp_dir() . DIRECTORY_SEPARATOR . getpid();
mkdir($tmp);

Another fix would be to use a folder within the data/ folder of the project, which is project-specific:

$tmp = sfConfig::get('sf_data_dir') . DIRECTORY_SEPARATOR . 'doctrine_tmp';

(We use the latter approach in pkToolkitPlugin)



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

How about this patch?

Index: lib/Doctrine/Migration/Diff.php
===================================================================
--- lib/Doctrine/Migration/Diff.php	(revision 6893)
+++ lib/Doctrine/Migration/Diff.php	(working copy)
@@ -45,7 +45,8 @@
                                 'created_indexes'     =>  array(),
                                 'dropped_indexes'     =>  array()),
               $_migration,
-              $_startingModelFiles = array();
+              $_startingModelFiles = array(),
+              $_tmpPath;
 
     protected static $_toPrefix   = 'ToPrfx',
                      $_fromPrefix = 'FromPrfx';
@@ -68,6 +69,7 @@
         $this->_from = $from;
         $this->_to = $to;
         $this->_startingModelFiles = Doctrine_Core::getLoadedModelFiles();
+        $this->setTmpPath(sys_get_temp_dir() . DIRECTORY_SEPARATOR . getmypid());
 
         if ($migration instanceof Doctrine_Migration) {
             $this->_migration = $migration;
@@ -77,6 +79,20 @@
     }
 
     /**
+     * Set the temporary path to store the generated models for generating diffs
+     *
+     * @param string $tmpPath
+     * @return void
+     */
+    public function setTmpPath($tmpPath)
+    {
+        if ( ! is_dir($tmpPath)) {
+            mkdir($tmpPath, 0777, true);
+        }
+        $this->_tmpPath = $tmpPath;
+    }
+
+    /**
      * Get unique hash id for this migration instance
      *
      * @return string $uniqueId
@@ -301,7 +317,7 @@
      */
     protected function _generateModels($prefix, $item)
     {
-        $path = sys_get_temp_dir() . DIRECTORY_SEPARATOR . strtolower($prefix) . '_doctrine_tmp_dirs';
+        $path = $this->_tmpPath . DIRECTORY_SEPARATOR . strtolower($prefix) . '_doctrine_tmp_dirs';
         $options = array(
             'classPrefix' => $prefix,
             'generateBaseClasses' => false
@@ -357,7 +373,7 @@
         }
 
         // clean up tmp directories
-        Doctrine_Lib::removeDirectories(sys_get_temp_dir() . DIRECTORY_SEPARATOR . strtolower(self::$_fromPrefix) . '_doctrine_tmp_dirs');
-        Doctrine_Lib::removeDirectories(sys_get_temp_dir() . DIRECTORY_SEPARATOR . strtolower(self::$_toPrefix) . '_doctrine_tmp_dirs');
+        Doctrine_Lib::removeDirectories($this->_tmpPath . DIRECTORY_SEPARATOR . strtolower(self::$_fromPrefix) . '_doctrine_tmp_dirs');
+        Doctrine_Lib::removeDirectories($this->_tmpPath . DIRECTORY_SEPARATOR . strtolower(self::$_toPrefix) . '_doctrine_tmp_dirs');
     }
 }
Comment by Tom Boutell [ 08/Dec/09 ]

Looks good

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

Thanks for helping with the issue. It is fixed now.





[DC-332] Doctrine_Migration_Diff doesn't work when plugin schemas are present but there is no app schema Created: 07/Dec/09  Updated: 02/Mar/10  Resolved: 02/Mar/10

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

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

Symfony 1.3



 Description   

A project with plugin schemas, but no project-level schema, which Symfony is otherwise fine with:

svn co http://svn.symfony-project.com/plugins/pkContextCMSPlugin/sandbox/branches/1.3 cmstest13
cd cmstest13
./symfony doctrine:generate-migrations-diff

>> doctrine generating migration diff
>> file+ /private/var/folders/3H/3Hu3TTyjFt...TI/Tmp/doctrine_schema_81204.yml

Notice: Undefined variable: extension in /Users/boutell/Sites/cmstest13-jonwagetest/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Diff.php on line 320

Notice: Undefined variable: extension in /Users/boutell/Sites/cmstest13-jonwagetest/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Diff.php on line 324

No php or yml files found at path: "/Users/boutell/Sites/cmstest13-jonwagetest/lib/model/doctrine"



 Comments   
Comment by Jonathan H. Wage [ 02/Mar/10 ]

I fixed this at some point. It was fixed by http://trac.doctrine-project.org/changeset/7067

Please confirm or re-open if you have any issues.

Thanks, Jon





[DC-323] when inserting a record into sql server (via odbc) doctrine fails to get last inserted ID Created: 03/Dec/09  Updated: 15/Mar/10  Resolved: 15/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.0
Fix Version/s: 1.2.2

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

windows XP SP3, SQL server version
[major] => 9
[minor] => 00
[patch] => 4035
[extra] =>
[native] => Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)
Nov 24 2008 13:01:59
Copyright (c) 1988-2005 Microsoft Corporation
Express Edition on Windows NT 5.1 (Build 2600: Service Pack 3))


Attachments: Text File ff.txt     Text File mssql.patch     Text File mssql2.patch    

 Description   

in Doctrine/Sequence/Mssql.php the function lastInsertId() fails to retrieve the last inserted ID when inserting a record. Because the major release of my sql server is bigger than 8, it chooses $query = 'select SCOPY_IDENTITY()' which does not return a number (in fact it does not return anything), although the record IS inserted succesfully. The backtrace is attached.
If, on the other hand, I force doctrine to use 'select @@IDENTITY' the query does return the correct number and everything goes fine!
So I think the conditions which query to choose is incorrect. I tried both queries in SQL server itself and both queries returned the right number. But one of them gets lost somewhere when using it in doctrine.



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

Microsoft SQL Server works in a such way, that different things have different scopes. Running query as prepared statement and then executing it results in different scope, hence running "select scope_identity()" after this query returns nothing. This is expected behaviour, and this is how Microsoft SQL Server should work.

To overcome this issue, I used a popular "hack" (maybe not really a hack) - add this query to the actual query (more here http://forums.devshed.com/ms-sql-development-95/insert-and-return-the-primary-key-232783.html or all other the web):

INSERT INTO X VALUES(1,1,2); SELECT SCOPE_IDENTITY();

Only using this way, I managed to make my component (Zend_Db_Adapter_Sqlsrv) to work. However, since Doctrine is very different and INSERT method is processed in completely different fashion I don't think that there is a way to overcome this issue.

Comment by aiso haikens [ 03/Dec/09 ]

unfortunately, retrieving the lastInsertedId() is part of the insert() functionality. So an exception is thrown everytime I try to insert a new record, which I must overcome (the record is by the way perfectly added to the db)

For me there is a perfect workaround: just use 'select @@IDENTITY' which works flawlessly.

So this is the point: I think more often 'select @@IDENTITY' must be chosen over 'select SCOPY_IDENTITY()' 'cause the latter does not (always?) return the id.

Comment by Juozas Kaziukenas [ 03/Dec/09 ]

I googled some more:

http://blog.sqlauthority.com/2007/03/25/sql-server-identity-vs-scope_identity-vs-ident_current-retrieve-last-inserted-identity-of-record/
http://beyondrelational.com/blogs/jacob/archive/2009/02/05/sql-server-identity-scope-identity-and-ident-current.aspx

Basically @@IDENTITY works in most cases, but it can go very wrong if you have triggers or stuff like that (which is not that rare in mssql world).

However, since with scope_identity() there are problems, I would say that Doctrine should use @@IDENTITY, because SCOPE_IDENTITY() will never return a value. Just impossible to fix.

Comment by aiso haikens [ 04/Dec/09 ]

Ah, I see, you are right, @@IDENTITY has to many drawbacks.

But in the first link you provided was the answer to overcome scope and trigger problems: the best option should be to actually use 'select IDENT_CURRENT('table_name')'. I just tested it and it works perfect! You only need to pass the table name in UnitOfWork.php in case the driver is mssql.

Comment by Juozas Kaziukenas [ 04/Dec/09 ]

I've attached a possible fix.

Test it if you can and when approved I will commit it.

Comment by aiso haikens [ 09/Dec/09 ]

I tested your patch, but it didn't work since the $table var is empty in my case. This is because the function _assignIdentifier() in UnitOfWork won't set the $seq var in case of 'mssql'. So first of all we need to pass the table name to this function like this in UnitOfWork line 925:

+ } elseif ($driver == 'oracle' || $driver == 'mssql')

{ $seq = $table->getTableName(); }

$id = $this->conn->sequence->lastInsertId($seq);

And furthermore I need to quote the table name before it worked like this in Mssql line 141:

$query = 'SELECT IDENT_CURRENT(\'' . $this->conn->quoteIdentifier($table) . '\')';

After these changes it worked. But don't you think we have to get rid of the SCOPE_IDENTITY entirely?
I attached this patch.

Comment by aiso haikens [ 19/Dec/09 ]

OK, what to do next? The last patch works fine for me. It seems to be the solution to the problem. So, can I check it in? Or should someone else do this? Or do I simply set the status to 'resolve' and someone else does the rest?

Comment by Craig Marvelley [ 03/Mar/10 ]

I tried the last patch and it works fine for me on SQL Server 2005/2008. +1 for committing it

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

Thanks for everyones work on this issue.

Comment by Brian B. [ 15/Mar/10 ]

Tried the patch and it works on SQL Server 2005 as well. Lots of fun trying to find it. Thanks for the fix.





[DC-320] Doctrine_Record fails to correctly update columns named data (conflict with getData method) Created: 03/Dec/09  Updated: 12/Mar/10  Resolved: 02/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Record
Affects Version/s: 1.2.0
Fix Version/s: 1.2.2

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

linux, apache 2, mysql 5.1, php 5.2



 Description   

I have a table with a "data" column (DATE type but the issue is not strictly related to the datatype), when updating/insering a record it fails with this error:

strtotime() expects parameter 1 to be string, array given in /usr/share/pear/Doctrine/lib/Doctrine/Record.php on line 1526

With some debugging I found that the value stored in $old was the internal $data array, and not my value. I assume that there's a conflict with the get/setData methods.

Thanks.



 Comments   
Comment by Massimiliano Torromeo [ 04/Dec/09 ]

I noticed another problem related to this:
when I dump the data with "doctrine dump-data" the resulting yaml is corrupted on records with fields named "data"

Comment by Juozas Kaziukenas [ 04/Dec/09 ]

This is caused by the column having a name "data".

Because if you have Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE enabled, Doctrine fill try method setField and getField and hence setData and getData breaks it.

I recommend changing a field name or disabling this option. Otherwise, this issue is Invalid (but probably need to be documented more).

Comment by Massimiliano Torromeo [ 04/Dec/09 ]

I started using Doctrine on a pre-existing database and changing all the data fields is really troublesome right now, and having AUTO_ACCESSOR_OVERRIDE would be nice.
I temporarily solved my problem by changing line 1321 of Record.php with:

if ($fieldName!="data" && $this->_table->getAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE) || $this->hasAccessor($fieldName)) {

This way I only lose the possibility of having a custom accessor for the data field and not all the others.
I still think this can be fixed, without having to disable AUTO_ACCESSOR_OVERRIDE.

If this is not a BUG maybe it could be considered a feature request then?

Comment by Juozas Kaziukenas [ 05/Dec/09 ]

I understand you, sometimes adopting a framework can be a pain

Problem is coming from the lines:

if ($load) {
$old = $this->get($fieldName, $load);
} else {
$old = $this->_data[$fieldName];
}

in _set method of Doctrine_Record. Here it calls get('data') method and your problem occurs.

Speaking of solution for this I'm not sure what is a way - field name "data" is reserved in Doctrine mainly because there is a method set/getData. However, in the same way a lot of fields can create this problem - just search for methods staring with get and you will find a bunch of them. All these will fail if your column is named the same.
From my point of view, it is how Doctrine is written and it's quite hard to change it now - you have getX for both your custom mutators and Doctrine methods as well. I don't know any possible way how to distinguish between them and only possible way seems to be that option ACCESSOR_OVERRIDE which only means that you need to register your custom code as mutators (very easy).

I didn't managed to find a documentation about this, so I guess we need to wait for someone in a higher level to comment. Right now I see it as invalid/won't fix mainly because it would require a major rewrite of a lot code to remove that ambiguity between method names and I would suggest disabling override, but it's just me

Comment by Jamie Learmonth [ 05/Dec/09 ]

This should get picked up in the generator classes and the developer should be notified as this error occurring at runtime is a real time consumer to debug.

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

Can you test this patch? It will throw an exception if you use a invalid field name:

Index: lib/Doctrine/Import/Builder.php
===================================================================
--- lib/Doctrine/Import/Builder.php	(revision 6882)
+++ lib/Doctrine/Import/Builder.php	(working copy)
@@ -508,9 +508,25 @@
      */
     public function buildColumns(array $columns)
     {
+        $manager = Doctrine_Manager::getInstance();
+        $refl = new ReflectionClass($this->_baseClassName);
+
         $build = null;
         foreach ($columns as $name => $column) {
             $columnName = isset($column['name']) ? $column['name']:$name;
+            if ($manager->getAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE)) {
+                $e = explode(' as ', $columnName);
+                $fieldName = isset($e[1]) ? $e[1] : $e[0];
+                $classified = Doctrine_Inflector::classify($fieldName);
+                $getter = 'get' . $classified;
+                $setter = 'set' . $classified;
+
+                if ($refl->hasMethod($getter) || $refl->hasMethod($setter)) {
+                    throw new Doctrine_Import_Exception(
+                        sprintf('When using the attribute ATTR_AUTO_ACCESSOR_OVERRIDE you cannot use the field name "%s" because it is reserved by Doctrine. You must choose another field name.', $fieldName)
+                    );
+                }
+            }
             $build .= "        ".'$this->hasColumn(\'' . $columnName . '\', \'' . $column['type'] . '\'';
 
             if ($column['length']) {
Comment by Massimiliano Torromeo [ 08/Dec/09 ]

I can test the patch in a couple of days, I'll post the results here.
Thanks.

Comment by Massimiliano Torromeo [ 31/Dec/09 ]

Sorry for the long delay. I applied the patch but I don't know when it is supposed to throw the exception.
It doesn't warn on existing databases does it?

Comment by Pawel [ 13/Jan/10 ]

Try to modify file Doctrine/lib/Doctrine/Record.php at line: 1433
I don't know if this is the best solution but works for me.
if ($load) {
if ($fieldName == 'data')

{ $old = $this->get($fieldName, $load); $old = $old['data']; }

else

{ $old = $this->get($fieldName, $load); }

} else

{ $old = $this->_data[$fieldName]; }
Comment by Jonathan H. Wage [ 02/Mar/10 ]

It only throws exceptions when you build your classes.

Comment by Thomas Keller [ 12/Mar/10 ]

The exception doesn't work for me either, though the field(s) which make problems here are `name` and `description`. More information can be found here: <http://github.com/sympal/sympal/issues/issue/7/#comment_157161>





[DC-319] getModified() returns object where ids are expected Created: 03/Dec/09  Updated: 02/Mar/10  Resolved: 02/Mar/10

Status: Resolved
Project: Doctrine 1
Component/s: Record, Relations
Affects Version/s: 1.1.7, 1.2.1
Fix Version/s: 1.2.2

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

PHP 5.2.10 on Ubuntu 9.10



 Description   

Assigning a new unsaved relation to an entity confuses getModified() to return records for values such as userId, that are expected to be ints.

Here is a full example to reproduce:

<?php
require_once '_loader.php';

$mgr = Doctrine_Manager::getInstance();
$mgr->openConnection('....');

class User extends Doctrine_Record
{
    public function setTableDefinition()
    {
        $this->setTableName('t_users');

        $this->hasColumn('name', 'string', 32);
    }
}

class Post extends Doctrine_Record
{
    public function setTableDefinition()
    {
        $this->setTableName('t_posts');

        $this->hasColumn('body', 'string', 256);
        $this->hasColumn('userId', 'integer');
    }

    public function setUp()
    {
        $this->hasOne('User', array(
            'local'   => 'userId',
            'foreign' => 'id'
        ));
    }
}

Doctrine::dropDatabases();
Doctrine::createDatabases();
Doctrine::createTablesFromArray(array('User', 'Post'));

$joe = new User();
$joe->name = 'Joe';
$joe->save();

$post = new Post();
$post->body = 'Hi';
$post->User = $joe;
$post->save();

$bill = new User();
$bill->name = 'Bill';
//$bill->save(); // If this is uncommented everything works fine

$post->User = $bill;

var_dump(' --- New --- ');
var_dump($post->getModified());

And instead of a id for userId I get this

string(13) " --- New --- "
array(1) {
  ["userId"]=>
  object(User)#37 (18) {
    ["_node:protected"]=>
    NULL
    ["_id:protected"]=>
    array(0) {
    }
    ["_data:protected"]=>
    array(2) {
      ["id"]=>
      object(Doctrine_Null)#4 (0) {
      }
      ["name"]=>
      string(4) "Bill"
    }
    ["_values:protected"]=>
    array(0) {
    }
    ["_state:protected"]=>
    int(2)
    ["_lastModified:protected"]=>
    array(0) {
    }
    ["_modified:protected"]=>
    array(1) {
      [0]=>
      string(4) "name"
    }
    ["_oldValues:protected"]=>
    array(1) {
      ["name"]=>
      NULL
    }
    ... trimmed ...

expected

string(13) " --- New --- "
array(1) {
  ["userId"]=>
  string(1) "2"
}

Tested on 1.1 and 1.2 branches from svn. (same result)



 Comments   
Comment by Jonathan H. Wage [ 02/Mar/10 ]

This is the expected behavior. Because you haven't saved $bill yet, it is temporarily storing the reference to the object in the foreign key field.

Comment by Emil Vladev [ 02/Mar/10 ]

But sholnd't it be NULL. userId is expected to be an int - not an object - doesn't feel right?!?

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

Hmm. I guess it could go either way. If you haven't saved yet, then the property has changed, we just don't know the id yet. I could imagine someone wanting to know that an object was assigned to that foreign key but not saved yet. Either way, I don't think we can change the behavior in Doctrine 1.2 if people might be relying on it already.





[DC-318] Doctrine_Table::find(x) fails for odbc/mssql connection due to limit() clause Created: 03/Dec/09  Updated: 22/Mar/10  Resolved: 02/Mar/10

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

Type: Bug Priority: Major
Reporter: aiso haikens Assignee: Jonathan H. Wage
Resolution: Duplicate Votes: 0
Labels: None
Environment:

windows XP SP3


Attachments: Text File ff.txt     Text File mssqlimit.patch     Text File mssqllimit.patch     Text File mssqlllimit2.patch    
Issue Links:
Duplicate
is duplicated by DC-289 Using MSSQL connection the find metho... Closed

 Description   

call that fails is Doctrine::getTable('Building')->find(1). With mysql all is fine, but if I use MSSQL via odbc (SQL Native Client) I get an exception saying:
SQLSTATE[22018]: Invalid character value for cast specification: 206 [Microsoft][SQL Native Client][SQL Server]Er is een conflict met het type operand ontstaan: text is incompatibel met int (SQLExecute[206] at ext\pdo_odbc\odbc_stmt.c:254)
see attached stacktrace.
So find(1) fails but a call to e.g. findAll() works fine.

I found out that if I leave out the limit(1) from the function find() on line 1602 it gives me the correct object and no exception!
So actually what goes wrong is the limit(1) clause in this call:
$object = Doctrine_Query::create()>from('Building b')>where('b.id = 1')>limit(1)>fetchOne();
with getSqlquery() this becomes:
SELECT TOP 1 [inner_tbl].[id] AS [b__id] FROM (SELECT TOP 1 [b].[id] AS [b__id], [b].[version] AS [b__version], [b].[name] AS [b__name], [b].[number] AS [b__number], [b].[title_nl] AS [b__title_nl], [b].[title_en] AS [b__title_en], [b].[published] AS [b__published] FROM [building] [b] WHERE ([b].[id] = ?)) AS [inner_tbl]

If executed with sqlcmd.exe this gives an error saying 'no columnname id', what seems to be correct since it should be [inner_tbl].[b__id] iso [inner_table].[id], so I suspect that the modifyLimitQuery() function in Connection/Mssql.php is not correct either.

I can work around this problem by doing a fetchOne() iso find().



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

This is because of:

$field_array = explode(',', $fields_string);
$aux2 = explode('.', $field_array[0]);
$key_field = trim(end($aux2));

With query like SELECT t.id as t__id FROM X it works like this:

SELECT t.id as t__id FROM X – >
t.id as t__id -->
array('t.id as t__id') -->
array('t', '.id as t__id')

Which is wrong. It should split on "as" an then use it.

I created a patch for this, which should make it work. Test it if you can and I hopefully it will be included into source.

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

The patch looks good it just doesn't follow the coding standards. $variableName not $variable_name and

}
else
{

Should be

} else {

You might want to read up on the Doctrine coding standards. Whenever you commit something you must make 100% sure that it follows the standards. If you fix the coding standards in the patch you can commit it.

Comment by Juozas Kaziukenas [ 07/Dec/09 ]

I reattached updated patch, please review if that's what you meant and I will commit it. Variables names were already there, but I fixed them now

Comment by Michael Card [ 09/Dec/09 ]

All the if statements are unnecessary, look a few lines above, the 2-3 lines handle splitting on the as and "." without all the if statements. Related to issue DC-289

Comment by Juozas Kaziukenas [ 09/Dec/09 ]

Yes, somehow missed that one. This one should fix it

Comment by Juozas Kaziukenas [ 09/Dec/09 ]

I looked at DC-289 and it seems to be the same thing as this error. So I suggest closing this as duplicate and fixing that one with a patch provided.

Comment by aiso haikens [ 09/Dec/09 ]

I agree, it is a duplicate of DC-289. I will add my comments about this patch to that one.

Comment by Michael Card [ 18/Dec/09 ]

Should be closed as duplicate.

Comment by Gilberto [ 22/Mar/10 ]

Hello everyone, i'm new here but i'm having the same problem, but i'm not clear about the fixing, please could someone telme realy how can i patch the select sql problem whit mssql, i'm using symfony 1.4 and mssql server 2005, and when i do:

Doctrine_Query::CREATE()
->select('u.username')
->from('User u')
->execute();

then i get the messagge error:
SQLSTATE[HY000]: General error: 10007 Invalid
column name...

to resolve this is very important for me.

sorry my english





[DC-300] synchronizeWithArray deletes Entries in RefTable when updating related Entries Created: 30/Nov/09  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

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

Attachments: File DC300TestCase.php    

 Description   

You have Users and Groups with a ManyToMany relation (refClass = UserGroup).
Then you do a synchronizeWithArray() on a user:

 
$user->synchronizeWithArray(array(
    'Groups' => array(
        array('name' => 'updated Group')
    )
));

When you update a record with synchronizeWithArray() and you update ManyToMany related entries, the RefTable entries gets deleted.

I think the problem is located near:
Doctrine_Record line 2024:

 
        // Eliminate relationships missing in the $array
        foreach ($this->_references as $name => $relation) {
	        $rel = $this->getTable()->getRelation($name);
	
// PROBLEM: RefClass "UserGroup" will never be set in the sync-Array (just "Groups"), so all entries in UserGroup-Table will be deleted
// only new Groups that are synced will be created with a link in the refTable
		if ( ! isset($array[$name]) && ( ! $rel->isOneToOne() || ! isset($array[$rel->getLocalFieldName()]))) {
                    unset($this->$name);
                }
        }

TestCase follows.



 Comments   
Comment by Marcus Häußler [ 30/Nov/09 ]

TestCase

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

This one is proving to be very tricky to fix. Any suggestions or ideas for solutions would be appreciated.

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

Is there any possibilty to check wether a relation is used as "refClass"?
In setUp() you say hasMany(array([..], 'refClass' => 'UserGroup')), but i could not find this information in the relation-object.

Then you could do something like this

if ( ! isset($array[$name]) && ( (!$rel->isRefClass() && ! $rel->isOneToOne()) || ! isset($array[$rel->getLocalFieldName()]))) {
    unset($this->$name);
}

The unlinking works anyway.

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

This fixes your test case but I want to test it before we include it in a release(1.2.2)

Index: lib/Doctrine/Relation.php
===================================================================
--- lib/Doctrine/Relation.php	(revision 6882)
+++ lib/Doctrine/Relation.php	(working copy)
@@ -74,6 +74,8 @@
                                   'orderBy' => null
                                   );
 
+    protected $_isRefClass = null;
+
     /**
      * constructor
      *
@@ -416,6 +418,24 @@
         }
     }
 
+    public function isRefClass()
+    {
+        if ($this->_isRefClass === null) {
+            $this->_isRefClass = false;
+            $table = $this->getTable();
+            foreach ($table->getRelations() as $name => $relation) {
+                foreach ($relation['table']->getRelations() as $relation) {
+                    if (isset($relation['refTable']) && $relation['refTable'] === $table) {
+                        $this->_isRefClass = true;
+                        break(2);
+                    }
+                }
+            }
+        }
+
+        return $this->_isRefClass;
+    }
+
     /**
      * __toString
      *
Index: lib/Doctrine/Record.php
===================================================================
--- lib/Doctrine/Record.php	(revision 6882)
+++ lib/Doctrine/Record.php	(working copy)
@@ -2024,8 +2024,8 @@
         // Eliminate relationships missing in the $array
         foreach ($this->_references as $name => $relation) {
 	        $rel = $this->getTable()->getRelation($name);
-	
-			if ( ! isset($array[$name]) && ( ! $rel->isOneToOne() || ! isset($array[$rel->getLocalFieldName()]))) {
+
+            if ( ! $rel->isRefClass() && ! isset($array[$name]) && ( ! $rel->isOneToOne() || ! isset($array[$rel->getLocalFieldName()]))) {
                 unset($this->$name);
             }
         }
Index: tests/Ticket/DC300TestCase.php
===================================================================
--- tests/Ticket/DC300TestCase.php	(revision 0)
+++ tests/Ticket/DC300TestCase.php	(revision 0)
@@ -0,0 +1,127 @@
+<?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.phpdoctrine.org>.
+ */
+
+/**
+ * Doctrine_Ticket_DC300_TestCase
+ *
+ * @package     Doctrine
+ * @author      Konsta Vesterinen <kvesteri@cc.hut.fi>
+ * @license     http://www.opensource.org/licenses/lgpl-license.php LGPL
+ * @category    Object Relational Mapping
+ * @link        www.phpdoctrine.org
+ * @since       1.0
+ * @version     $Revision$
+ */
+class Doctrine_Ticket_DC300_TestCase extends Doctrine_UnitTestCase
+{
+    public function prepareData()
+    {
+        $g1 = new Ticket_DC300_Group();
+        $g1['name'] = 'group1';
+        $g1->save();
+
+        $g2 = new Ticket_DC300_Group();
+        $g2['name'] = 'group2';
+        $g2->save();
+
+        $g3 = new Ticket_DC300_Group();
+        $g3['name'] = 'group3';
+        $g3->save();
+
+        $u1 = new Ticket_DC300_User();
+        $u1['name'] = 'user1';
+        $u1['Groups']->add($g1);
+        $u1['Groups']->add($g2);
+        $u1->save();
+    }
+
+    public function prepareTables()
+    {
+        $this->tables[] = 'Ticket_DC300_Group';
+        $this->tables[] = 'Ticket_DC300_User';
+        $this->tables[] = 'Ticket_DC300_UserGroup';
+        parent::prepareTables();
+    }
+
+    public function testRefTableEntriesOnManyToManyRelationsWithSynchronizeWithArray()
+    {
+		$u1 = Doctrine::getTable('Ticket_DC300_User')->find(1);
+
+		// update the groups user (id 1) is linked to
+		$u1->synchronizeWithArray(array(
+			'Groups' => array(
+				array('name' => 'group1 update'),
+				array('name' => 'group2 update')
+			)
+		));
+		$u1->save();
+
+		// update the user-objects with real data from database
+		$u1->loadReference('Groups');
+
+		// check wether the two database-entries in RefTable exists
+		$this->assertEqual(count($u1->Groups), 2);
+    }
+   
+}
+
+class Ticket_DC300_Group extends Doctrine_Record
+{
+	public function setTableDefinition()
+	{
+		$this->hasColumn('name', 'string', 255);
+	}
+	
+	public function setUp()
+	{
+		$this->hasMany('Ticket_DC300_User as Users', array(
+			'local' => 'group_id',
+			'foreign' => 'user_id',
+			'refClass' => 'Ticket_DC300_UserGroup'
+		));
+	}
+}
+
+class Ticket_DC300_User extends Doctrine_Record
+{
+	public function setTableDefinition()
+	{
+		$this->hasColumn('name', 'string', 255);
+	}
+
+	public function setUp()
+	{
+		$this->hasMany('Ticket_DC300_Group as Groups', array(
+			'local' => 'user_id',
+			'foreign' => 'group_id',
+			'refClass' => 'Ticket_DC300_UserGroup'
+		));
+	}
+}
+
+class Ticket_DC300_UserGroup extends Doctrine_Record
+{
+	public function setTableDefinition()
+	{
+		$this->hasColumn('user_id', 'integer');
+		$this->hasColumn('group_id', 'integer');
+	}
+}
\ No newline at end of file
Comment by Marcus Häußler [ 09/Dec/09 ]

I tested your patch in our project and it seems to work very well.

Thank you and your team for the good work !





[DC-289] Using MSSQL connection the find method for models does not work Created: 25/Nov/09  Updated: 02/Mar/10  Resolved: 02/Mar/10

Status: Closed
Project: Doctrine 1
Component/s: Connection
Affects Version/s: 1.2.0-RC1
Fix Version/s: 1.2.2

Type: Bug Priority: Major
Reporter: Trevor Lanyon Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 3
Labels: None
Environment:

php 5.3.1,
Symfony 1.4.0-DEV
Doctrine 1.2.0-RC1
pdo_mssql (libdb)


Attachments: File Mssql-Patch-20091218.php     File Mssql-Patch-20091221.php     File Mssql-Patch-20091222.php    
Issue Links:
Duplicate
duplicates DC-318 Doctrine_Table::find(x) fails for odb... Closed

 Description   

using a doctrine generated class's find method produced erroneous SQL such as:

SELECT TOP 1 [inner_tbl].[id] AS [b__id] FROM (SELECT TOP 1 [b].[id] AS [b__id], [b].[name] AS [b__name], [b].[alias] AS [b__alias], [b].[ip] AS [b__ip], [b].[operator_id] AS [b__operator_id], [b].[cell_id] AS [b__cell_id], [b].[latitude] AS [b__latitude], [b].[longtitude] AS [b__longtitude], [b].[community_read] AS [b__community_read], [b].[community_write] AS [b__community_write], [b].[last_found_at] AS [b__last_found_at], [b].[active] AS [b__active], [b].[type] AS [b__type], [b].[poll_mac_behind_sus] AS [b__poll_mac_behind_sus], [b].[created_at] AS [b__created_at] FROM [basestation] [b] WHERE ([b].[id] = '2')) AS [inner_tbl]

commenting out the following line (193) in' function modifyLimitQuery' for lib/Doctrine/Connection/Mssql.php

$query = preg_replace('/^'.$selectRegExp.'/i', $selectReplace . 'TOP ' . ($count + $offset) . ' ', $query);

//$query = 'SELECT TOP ' . $count . ' ' . $this->quoteIdentifier('inner_tbl') . '.' . $key_field . ' FROM (' . $query . ') AS ' . $this->quoteIdentifier('inner_tbl');

if ($orderby !== false) {

It appears to have worked. This method was part of jwage's commit for change set 6795 (http://trac.doctrine-project.org/changeset/6795/branches/1.2/lib/Doctrine/Connection/Mssql.php) so there must be a reason for this change. This is very preliminary. If the change works there is a considerable amount of refactoring that way be done. I will commit a proper patch once I am able to test exhaustively, at the moment this is a show stopper and I need to continue development.



 Comments   
Comment by Michael Card [ 26/Nov/09 ]

Trevor,

I had worked on these changes the jwage committed as I couldn't find any way how the old code worked. Did this code work in versions before 1.2.0-RC1 or are you just finding this using the new version?

What code are you using for the find? The code works okay when running a normal dql query.

Mike

Comment by Trevor Lanyon [ 26/Nov/09 ]

Michael,

It seems as though I first encountered the problem after I did an svn update. I can assume that it was changeset 6795 as the problem is created in lib/Doctrine/Connection/Mssql.php and the weeks before changeset 6795 the exact same code worked.

The dql does work very well. I don't really use find methods too often as I like to bring my models back with as few loads as possible and most of my models aren't flat enough to use a find.

I found the error mostly with the pages that were generated by symonfy as doctrine:generate-model generates lines such as : $this->forward404Unless($Basestation = Doctrine::getTable('Basestation')>find(array($request>getParameter('id'))), sprintf('Object Basestation does not exist (%s).', $request->getParameter('id'));

The problem is very obvious. The changeset removed the 'SELECT *' and tried to do a 'SELECT

{key}'. The {key}

is referring to the raw column name but is selecting from a subquery that has already aliased the

{key} field so it comes back with an error. I imagine there's a reason for only selecting the {key}

but I haven't encountered that yet. Once I have code that breaks with my change I will be able to implement a better fix.

For now it seems to be working.

Comment by Michael Card [ 30/Nov/09 ]

Hey Trevor,

Commenting out the line like you did won't work when using both a limit and an offset, you have to have the inner and outer queries to have the limit and offset work correctly.

Regular dql does a "select ... from table where key in (limit suquery here)" for the limit subquery has to only return 1 field.

What did you mean by "The

{key} is referring to the raw column name but is selecting from a subquery that has already aliased the {key}

field so it comes back with an error." Maybe I can work out some code that works in all situations.

Mike

Comment by Trevor Lanyon [ 30/Nov/09 ]

Hi Micheal,

"Commenting out the line like you did won't work when using both a limit and an offset, you have to have the inner and outer queries to have the limit and offset work correctly."

– exactly.

I finally had need for a limit on Friday and had started working on a proper adjustment. If it is something that you might be able to do that would be fantastic.

"What did you mean by "The

{key} is referring to the raw column name but is selecting from a subquery that has already aliased the {key}

field so it comes back with an error." Maybe I can work out some code that works in all situations."

If you look at the SQL that is in the first comment I appended you'll see:

'
SELECT TOP 1 [inner_tbl].[id] AS [b__id] FROM (SELECT TOP 1 [b].[id] AS [b__id], [b].[name] AS [b__name], ..................
'

Which will cause an error as the first statement "SELECT TOP [inner_tbl].[id] AS [b__id] FROM " tries to select [inner_tbl].[id] however [inner_tbl].[id] does not exist, it has been aliased to [inner_tbl].[[b__id] as per the SQL in the inner join.

I hope that is more clear.

I'm going to fumble around the code a little this morning and see if I can come up with something.

Thank you Michael.

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

Any updates or new information on this issue?

Comment by Michael Card [ 09/Dec/09 ]

I'm working on a fix, have something in a couple days.

Comment by aiso haikens [ 09/Dec/09 ]

Hi, I will put my comments to DC-318 here since it is a duplicate of this one.

the last patch of DC-318 gives this sql statement:
SELECT TOP 1 [inner_tbl].[b__id] FROM (SELECT TOP 1 [b].[id] AS [b__id], [b].[version] AS [b__version], [b].[name] AS [b__name], [b].[number] AS [b__number], [b].[title_nl] AS [b__title_nl], [b].[title_en] AS [b__title_en], [b].[published] AS [b__published] FROM [building] [b] WHERE ([b].[id] = ?)) AS [inner_tbl]

which is a correct sql statement if executed with sqlcmd.exe. But it still gives me the same exception as shown in the backtrace attached to DC-318.
But isn't it strange that just the id is return iso the complete record?? If I remove the limit(1) clause from the find function in Table.php it give this sql statement and works perfectly:
SELECT [b].[id] AS [b__id], [b].[version] AS [b__version], [b].[name] AS [b__name], [b].[number] AS [b__number], [b].[title_nl] AS [b__title_nl], [b].[title_en] AS [b__title_en], [b].[published] AS [b__published] FROM [building] [b] WHERE ([b].[id] = ?)

Comment by Michael Card [ 10/Dec/09 ]

Its more complicated, I'll write a patch this weekend.

It needs to be broken out to use seperate functions for modifyLimitQuery and modifyLimitSubQuery, the one function is trying to handle two different things. For a simple dql statement the modifyLimitQuery needs to return all fields. In a complex dql query, it needs to return the key field only as it is used as part of the where statement in the overall query.

Comment by Michael Card [ 18/Dec/09 ]

I'm attaching a patch Mssql-Patch-20091218.php. This should fix all the find problems and the pager problems.

Trevor and Aiso, can you test the patch before Jon applies it. I've tested it using regular dql querying, it needs to be tested using the find function and also using the pager. Two things to look for - does it work obviously, which means it fixed the field name error, and second, does it return all the fields, before it was only returning the id field.

Jon - To avoid tons of code duplicaton between modifyLimitQuery and modifyLimitSubQuery, I added a parameter to modifyLimitQuery, if this is no good, we can change it to just duplicate the code between the two functions.

Mike

Comment by aiso haikens [ 19/Dec/09 ]

Thanks Michael for the patch. I just tested it and it doesn't work. Still the same odbc exception when executing the sql statement. The exception goes like this:
SQLSTATE[22018]: Invalid character value for cast specification: 206 [Microsoft][SQL Native Client][SQL Server]Er is een conflict met het type operand ontstaan: text is incompatibel met int (SQLExecute[206] at ext\pdo_odbc\odbc_stmt.c:254)

the query that is finally produced by modifyLimitQuery() (so the one that fails) is:

SELECT * FROM (SELECT TOP 1 [inner_tbl].[b__id] FROM (SELECT TOP 1 [b].[id] AS [b__id], [b].[name] AS [b__name], [b].[published] AS [b__published] FROM [building] [b] WHERE ([b].[id] = ?)) AS [inner_tbl]) AS [outer_tbl]

Note that if I return the $query on line 194, just after the preg_replace, everything is fine. In that case the sql statement is (so basically the inner most select):

SELECT TOP 1 [b].[id] AS [b__id], [b].[name] AS [b__name], [b].[published] AS [b__published] FROM [building] [b] WHERE ([b].[id] = ?)

so, I have 2 questions:

  • why not return this last (working) query in this case? Why bother with doing the 3 nested selects?
  • I don't see how the nested queries can work in the first place since the second query selects only the id, iso the complete entry. I tried this : 'SELECT TOP 1 [b].[id] AS [b__id] FROM [building] [b] WHERE ([b].[id] = ?)' and although I do not get an exception I don't get the right record! But not very suprising to me since you return only an id.

Note that if I run the failing query (so the 3 nested selects) in SQL Server Manager I get the id without problems, so the statement itself is correct (although I do not think it is correct only to return the id). So maybe this is a problem in pdo_odbc only?

Comment by aiso haikens [ 19/Dec/09 ]

Hi Michael, I completely missed the rest of your last comment, sorry about that: so my questions are a bit awkward. I read also that in some cases it is necessary to use the nested selects.
To comment on your 2 things to look for: it does work in the sense that the field name error is solved, but wrt your second thing: maybe all fields are return in the end but I could not test this properly since the pdo_odbc will not tolerate the nested selects construction so it seems.

Note that I get the same exception when using only 2 selects like this:
SELECT * FROM (SELECT TOP 1 [b].[id] AS [b__id], [b].[name] AS [b__name], [b].[published] AS [b__published] FROM [building] [b] WHERE ([b].[id] = ?)) AS [outer_tbl]

Comment by aiso haikens [ 20/Dec/09 ]

I figured out that my app suffers from a very old bug in the SQL server client app. See http://bugs.php.net/bug.php?id=36561

It says it cannot handle bound params in a subquery! So I don't know how you fellows make this work??? It basically means that all this code is useless since it will never work for mssql until microsoft comes up with a solution!

I just upgraded from sql server 2005 express to 2008 express to see if that helped but it didn't. So this is a very disturbing bug that is in the code since 2006 and till this day is never solved....

So, are there any versions of mssql server that can handle these subqueries, I wonder? What do you guys use to make this work??? I think the conclusion is that pdo_odbc and doctrine will never work.

Comment by Trevor Lanyon [ 21/Dec/09 ]

Hi Michael and Aiso,

I had ran into that problem with sub query casting integers as strings. That cost me about 4 hours. I had to go into the Query Analyzer to find that pdo_lib was encapsulating the integers in quotation marks (making them strings) even though the query debug window was showing them without encapsulation. Although it is a terrible solution I embedded the integers directly into the SQL. It was the only option and it worked good enough (for now).

I agree that mssql (using pdo_lib for connectivity) might be too limited. As well as the bug you've indicated pdo_lib also limits column names to 30 characters. These limitations are very, very frustrating.

In regards to the patch I'm still generating errors:

SQLSTATE[HY000]: General error: 207 General SQL Server error: Check messages from the SQL Server [207] (severity 16) [(null)]

With the following code:

45 $q = Doctrine::getTable( 'Radiusdat' )->createQuer