[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-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-403] Eliminate queries produced by Doctrine_Node_NestedSet::getDescendants() when possible Created: 06/Jan/10  Updated: 16/Apr/10

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

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


 Description   

How to reproduce

  1. fetch a tree with nested set
    $root = Doctrine::getTable($model)->getTree()->findRoot($rootId);
    $treeObject= Doctrine::getTable($model)->getTree()->fetchTree($root->getId()); 
    
  2. issue
    $root->getNode()->getChildren();
    
    or there will be a total query mess in a lambda function with a loop getChildren().
    ...
    <?php foreach($root->getChildren() as $child): ?>
       ....
    <?php endforeach; ?>
    ...
    
    

Problem is described more verbosely here – http://codeutopia.net/blog/2008/08/30/understanding-doctrines-nestedset-feature/

What behavior is expected

An already fetched record instance is returned, without calling database and without causing query flooding.

Like in propel.

In propel if you are calling ....::retrieveTree($id) it returns the root
with completed, pooled (cached) and linked tree.

What happens

An additional query is issued

This is a big slip in architecture of Doctrine`s nested set implementation.






[DC-299] Doctrine::loadModels() returns an incorrect result if there is some models named before "Base" Created: 29/Nov/09  Updated: 30/Nov/09  Resolved: 30/Nov/09

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

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


 Description   

If there is a model named before "Base" (in the alpabetical order), like "Address", Doctrine::loadModels() returns an incorrect array by including the BaseAddress class :

Array
(
    [Address] => Address
    [BaseAddress] => BaseAddress
)

This happens because in the list of files, Address.class.php (where Address extends BaseAddress) comes before BaseAddress.class.php. So BaseAddress is already loaded when loadModels() checks if the BaseAddress class exists. Then this class is added in the loaded models without check if this is a valid model class.

This can be easily fixed :

// Doctrine/Core.php , line 679:

// replace :

$loadedModels[$className] = $className;

// by :
if (self::isValidModelClass($className)) {
  $loadedModels[$className] = $className;
}


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

Thanks for the ticket and fix.





[DC-295] Export_Schema does not properly account for classes that have a prefix. Created: 26/Nov/09  Updated: 30/Nov/09  Resolved: 30/Nov/09

Status: Resolved
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.2.0-BETA3, 1.2.0-RC1
Fix Version/s: 1.2.0

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


 Description   

When trying to run doctrine-cli generate-yaml-models (I think other tasks are affected too), I get a yaml file consisting of { }.
I think this is because on line 48 of Doctrine/Export/Schema.php $classPrefix is not passed to Doctrine_Core::loadModels($directory) even if it is set in the configuration array.
This is causing doctrine to think there are no models to generate the yaml for if I am using the $classPrefix.

I'm just learning Doctrine so it's entirely possibly something else is to blame for my issue, but this is where I was able to trace it to.



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

I fixed an issue similar to this last week. Make sure you're all fully up-to-date from the 1.2 branch and let me know if the problem still persists there.

Thanks, Jon

Comment by Matthew Miller [ 29/Nov/09 ]

I did an svn checkout from here http://svn.doctrine-project.org/branches/1.2/ and the behavior appears to be the same.

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

I added an attribute for setting the class prefix:

$manager->setAttribute(Doctrine_Core::ATTR_MODEL_CLASS_PREFIX, 'MyPrefix_');

Later we can make use of this attribute in more places possibly.

Comment by Matthew Miller [ 30/Nov/09 ]

I'll do some more testing to get a better idea of what's going on but here's what I've got so far.

line 627 of Core.php in the loadModelsfunction you have:

$classPrefix = $classPrefix === null ? $manager->getAttribute(Doctrine_Core::ATTR_MODEL_CLASS_PREFIX) : null;

Shouldn't the final null be $classPrefix? Otherwise I think you're overwriting a prefix that was passed as a parameter to the function.

When generating the models from the DB I pass options to the Doctrine_Cli that look something like:

$options['generate_models_options'] = array(
    'pearStyle' => true,
    'generateTableClasses' => true,
    'classPrefix' => 'Model_',
    'baseClassPrefix' => 'Base_',
    'baseClassesDirectory' => 'Base',
    'classPrefixFiles' => false,
    'generateAccessors' => false,
);

Would it make sense to use these or similar for generating the yaml from the models?

My initial test got me a little further but now it's having trouble loading the Base classes. It looks like this has to do with the baseClassPrefix and baseClassesDirectory but I'll test it more later.

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

Yes you are right, the line was wrong and the null should have been $classPrefix. As for the options, I am not sure. You will just need to play with different combinations until it works. Make sure that the class name and path to the file with the class in it are the same. That is how it is able to autoload the model classes.





[DC-288] Doctrine_Parser_Yml dependany on sfYaml causing issues for non symfony users Created: 25/Nov/09  Updated: 18/Feb/10  Resolved: 30/Nov/09

Status: Resolved
Project: Doctrine 1
Component/s: File Parser
Affects Version/s: 1.2.0
Fix Version/s: 1.2.0

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


 Description   

I am currently undergoing an integration with the Zend Framework. Unfortunatly we do not use the Symfony framework and have no scope available to include it.

The requirement for sfyaml in its rawest form has caused me to have to rewrite part of your parser to ensure it includes the crrect files which I have now included in our working version of Doctrine.

As Symfony appears to be distributed under an open license surely it would make sense for you to actually include this (or a modified version of this) into your library.

This would make the code much more portable and reusable for people who do not use symfony

My "Quick Fix" just involved dropping all the sfYaml files into the parser folder and doing a straight include untill I can find a more elegant solution



 Comments   
Comment by Ashley Broadley [ 27/Nov/09 ]

I could not get your 'quick fix' to work no matter whether i dumped the files in the parser dir, on my include path or anywhere.

Would it not be a good idea to reformat the sfYaml class names into the Pear/Zend/Doctrine scheme and integrate them into doctrine it's self?

for example:
File name:
sfYaml.php -> Doctrine/Parser/Yaml.php
Class name:
sfYaml -> Doctrine_Parser_Yaml

File name:
sfYamlDumper.php -> Doctrine/Parser/Yaml/Dumper.php
Class name:
sfYamlDumper -> Doctrine_Parser_Yaml_Dumper

etc...

If these files are going to be used as standard i would think it to be a good idea.

Comment by Matt Cockayne [ 27/Nov/09 ]

Hi Ashley

This link will show you how I added the files to create my quick fix from the files stored in my subversion repo.

http://subversion.zucchi.co.uk/listing.php?repname=titan&path=%2Ftrunk%2Flibrary%2FDoctrine%2FParser%2F#path_trunk_library_Doctrine_Parser_

As well as puutting the files in the parser dir I also had to change the requires at the top of the yaml.ph file.

Changeing the names of the classes would be a good idea for a more permanent fix but I will leave that to the good people at Doctrine to decide to put in place

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

I will fix the issue first thing this week. @Ashley, this is the way it used to be before this change. The issue is then we don't get bug fixes from sfYaml. It is better if we use it as a vendor library.

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

I moved the sfYaml external folder to the Parser folder. This should work better for everyone now.

Comment by Andreas Möller [ 03/Dec/09 ]

It's nice that one can now skip to add

/library/Doctrine

to the included paths, but it's not so nice that now the sfYaml files can not be found.

Comment by Exception e [ 06/Dec/09 ]

This ticket is not fixed. The doctrine autoloader should handle all it's dependencies, including those from symphony. These kind of things should not leak outside doctrine.

It took me quite some time to figure out. It is a severe bug.

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

hmm, What is the problem? The Doctrine::autoload() function does handle the autoloading of sfYaml now. Can you explain more detail about the problem you are encountering?

Comment by Matt Cockayne [ 06/Dec/09 ]

I had a problem too in it nit being handled by the autoloader. It may be down to how I have integrated Doctrine into my Zend Framework app, so I cant really comment on that one

the problem is easily fixed with a simple set of requires in the parser file. not ideal but it works for the moment

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

What was the problem? What was the error you got? I'd like to try and help fix something in Doctrine to make this handled better so any other more specific information anyone can provide would be much appreciated.

Comment by Peter Petermann [ 07/Dec/09 ]

In an Application using Zend Framework 1.9.6 and Doctrine 1.2,

$ doctrine-cli generate-models-yaml
PHP Fatal error: Class 'sfYaml' not found in /path/to//library/Doctrine/Doctrine/Parser/Yml.php on line 80
Fatal error: Class 'sfYaml' not found in /path/to/library/Doctrine/Doctrine/Parser/Yml.php on line 80

further investigation shows that the method in Core.php, which was modified with the new Path is never called.

the thing is, usually one sets up Zend Framework, so it uses the Doctrine autoloader
whenever a class is prefixed with Doctrine (by registering that namespace)
however, since sfYaml doesnt fall under that rule, the Zend Autoloader does not know that it needs to forward this, therefor the Doctrine one is never called.

A workarround is to add
require_once 'Doctrine.php';
$autoloader = Zend_Loader_Autoloader::getInstance();
$autoloader->registerNamespace('sfYaml')->pushAutoloader(array('Doctrine', 'autoload'), 'sfYaml');
to the Zend Booststrap class - like in your _initDoctrine method.

This, tbfh, is still an ugly workarround, but so is the sfYaml loading in the doctrine autoloader itself. Personally i agree with the OP, Doctrine should come as a complete package, not using symfony externals.

Comment by Lukas Kahwe [ 07/Dec/09 ]

Why is that "workaround" ugly? The fact of the matter is that not all code that is useful follows the same naming conventions. Having to fork or write wrappers around code with different naming conventions is a maintenance nightmare. Doctrine's autoloader implementation is a reference implementation but I assume most people use their own (by way of their chosen framework) and that one better be flexible enough to deal with different naming conventions. It seems ZF has these capabilities, so why is it ugly using them?

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

I see, so the problem is when you're not using Doctrine::autoload(). The thing is we seem to have problems no matter how we integrate sfYaml. Originally we had it setup as Doctrine_Parser_Yaml_SfYaml so it was just like a normal Doctrine class, but then it got out of date and we don't get the latest bug fixes. I changed it to be in lib/vendor/sfYaml and required it manually in the Doctrine code that used it. This causes problems if the project has already loaded sfYaml by other means. For example in a Symfony project sfYaml exists sometimes or if the user happens to use the sfYaml component in his project. So, it needs to be handled by the autoloader for sure I think.

Comment by Jeremy Hicks [ 16/Dec/09 ]

Edit: Looks like having this:

$manager->setAttribute(
Doctrine::ATTR_MODEL_LOADING,
Doctrine::MODEL_LOADING_CONSERVATIVE
);

in an Application Resource plug-in along with the CLI call stops the tables from getting created.

Autoloading the sfYaml stuff works for me now, but I'm having what appears to be a related problem. The Doctrine cli task "build-all-reload" is supposed to both recreate the database and generate the model files. It is generating the model files fine now. However, the database gets dropped and re-added, but none of the tables get re-added. The output says, "Created tables successfully" but after checking the DB they are not there. I'm using an application resource class, not a bootstrap init function, if that matters.

Comment by Michael Ekoka [ 18/Feb/10 ]

Currently using ZF 1.10 and Doctrine 1.2.1. To resolve this issue you need to ask Zend's Autoloader to register Doctrine's Autoloader for Doctrine and sfYaml namespaces:

$loader = Zend_Loader_Autoloader::getInstance();
$loader->pushAutoloader(array('Doctrine_Core','autoload'), array('Doctrine', 'sfYaml'));





[DC-286] Trailing DIRECTORY_SEPARATOR will cause Doctrine_Core::loadModels in PEAR mode to fail Created: 25/Nov/09  Updated: 30/Nov/09  Resolved: 30/Nov/09

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

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

Running Debian Lenny under Xen-64bit 1gig memory.

PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 26 2009 20:09:03)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans

Apache - not relevant - running from the command line.

mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (x86_64) using readlin.2


Attachments: File DC-286-Patch.diff    

 Description   

If I'm using the PEAR model loading in Doctrine, and I try to create the tables from the models as follows.

Doctrine::createTablesFromModels('/path/to/my/models/');

Doctrine doesn't recognise the models and can't create any tables as a result.
However if I remove the trailing slash.

Doctrine::createTablesFromModels('/path/to/my/models');

It works fine. This wasn't a problem is 1.2BETA-3. The problem is caused by changeset 6796, and the code that extracts the class name from the path of the filename not taking into account the trailing DIRECTORY_SEPARATOR.



 Comments   
Comment by Pete Hatton [ 25/Nov/09 ]

Patch for the issue.





[DC-283] Unsetting an invalid property Created: 24/Nov/09  Updated: 24/Nov/09  Resolved: 24/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Relations
Affects Version/s: 1.2.0-RC1
Fix Version/s: 1.0.14, 1.1.6, 1.2.0

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


 Description   

Actually I'm not sure how this issue could implicate on any behavior.
I was debbuging a project and I found this invalid reference:

Relation/Parser.php
public function bind($name, $options = array())
{
//...
    if ($this->hasRelation($alias)) {
        unset($this->relations[$alias]); // Doesn't exist, the right property is $this->_relations
        unset($this->_pending[$alias]);
    }
//...
}

I've started using Doctrine recently, so I think it's better somebody more expert take a look in that.






[DC-282] Memory Leak in Doctrine_Query_Abstract._getDqlCallbackComponents() Created: 24/Nov/09  Updated: 24/Nov/09  Resolved: 24/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Query
Affects Version/s: 1.1.5
Fix Version/s: 1.2.0

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

PHP 5.2.11, Apache 2.2, Ubuntu Linux 9.1



 Description   

The following iteration shows increasing memory usage:

 $manager = Doctrine_Manager::getInstance();
$manager->setAttribute(Doctrine::ATTR_USE_DQL_CALLBACKS, true);
$manager->....connection....

for($i=0; $i<10;$i++) {
  $tx = Doctrine_Query::create()
    ->from('Some_Entity cot')
    ->andWhere('cot.id = ?', $someid)
     ->fetchOne();
			
  $usage = memory_get_usage();
  echo $i.': '.$usage."\n";
}

This results in an exceed-max-memory-fatal (750 MB) with a more complex application i am running that iterates >20,000 times.
I found out that there is a memory leak in Doctrine_Query_Abstract._getDqlCallbackComponents():

...
$copy->getSqlQuery($params);
$componentsAfter = $copy->getQueryComponents();
$copy->free(); //This is the solution
...

Sincerly,
Markus






[DC-281] Generate Models Db changes case in Relationship definition. Created: 24/Nov/09  Updated: 24/Nov/09  Resolved: 24/Nov/09

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

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

Attachments: File lowercase-underscore-tables.sql     File pascal-case-tables.sql    

 Description   

Sorry - I'll start again.

So this is the scenario. generate-models-db or generate-yaml-db will not work for attachment: pascal-case-tables.sql but it does work with attachment: lowercase-underscore-tables.sql

The reason that this does not work is due to the builder incorrectly changing the case when you run generate-xxx-db on a database that has been generated with pascal case names (pascal-case-tables.sql).

This could be the reason the exception "Missing Class Name" is thrown when creating relationships due to the class that is physically generated according to the table name (for example BookingStatus). does not match the class name being searched for when creating relationships.

Create databases and run generate-models-db.



 Comments   
Comment by RV David [ 24/Nov/09 ]

changed booking to user - lack of sleep and too much caffeine makes for incoherent reports.

Comment by RV David [ 24/Nov/09 ]

Hopefully this will be more coherent. Sorry for spamming - I've been obsessing in trying to get this to work for the past day or so.





[DC-278] Invalid qubquery generated if using oracle adapter instead of pdo_oci Created: 23/Nov/09  Updated: 09/Jun/10

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

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

Linux, Oracle 10g



 Description   

Doctrine generates the following invalid subquery if oracle adapter is used (same query is generated corret if pdo_oci is used):

SELECT DISTINCT "s2"."code"
FROM "spend_category" "s2"
INNER JOIN "company_spend_category" "c4" ON ("s2"."code" = "c4"."spendcategory_code")
INNER JOIN "company" "c3" ON "c3"."code" = "c4"."company_code"
WHERE "s2"."code" = '19000000'
AND "c3"."is_deleted" IS NOT NULL
AND "s2"."is_deleted" IS NOT NULL
ORDER BY "c3"."name" desc

The problem is that the order by column is not part of the selected columns.

Sample dql statement to reproduce this error:

$this->pageAllPager = new Doctrine_Pager(
$q = Doctrine_Query::create()
->select('c.code, c.name, c.is_activated, c.is_deleted, sc.code')
->from('SpendCategory sc')
->innerJoin('sc.Companies c')
->where("sc.code = '$spendcategory'")
->addWhere('c.is_deleted IS NOT NULL')
->addWhere('sc.is_deleted IS NOT NULL')
->orderBy($orderBy)
->setHydrationMode(Doctrine::HYDRATE_ARRAY),
$page,
$resultsPerPage);
}



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

I believe this is fixed now in the latest Doctrine 1.2. Can you test and confirm?

Comment by Thomas Wahle [ 24/Nov/09 ]

It is not fixed with 1.2 RC1

Same sql wich work fine with pdo_oci generates an error using the oracle adapter

<p>
<b>Message:</b> ORA-01791: Kein mit SELECT ausgewählter Ausdruck : SELECT s.code AS s_code, c.code AS ccode, c.name AS cname, c.is_activated AS cis_activated, c.is_deleted AS c_is_deleted FROM spend_category s INNER JOIN company_spend_category c2 ON (s.code = c2.spendcategory_code) INNER JOIN company c ON c.code = c2.company_code WHERE s.code IN (SELECT a.code FROM ( SELECT DISTINCT s2.code FROM spend_category s2 INNER JOIN company_spend_category c4 ON (s2.code = c4.spendcategory_code) INNER JOIN company c3 ON c3.code = c4.company_code WHERE s2.code = '37000000' AND c3.is_deleted IS NOT NULL AND s2.is_deleted IS NOT NULL ORDER BY c3.name desc ) a WHERE ROWNUM <= 10) AND (s.code = '37000000' AND c.is_deleted IS NOT NULL AND s.is_deleted IS NOT NULL) ORDER BY c.name desc.

Failing Query: "SELECT s.code AS s_code, c.code AS ccode, c.name AS cname, c.is_activated AS cis_activated, c.is_deleted AS c_is_deleted FROM spend_category s INNER JOIN company_spend_category c2 ON (s.code = c2.spendcategory_code) INNER JOIN company c ON c.code = c2.company_code WHERE s.code IN (SELECT a.code FROM ( SELECT DISTINCT s2.code FROM spend_category s2 INNER JOIN company_spend_category c4 ON (s2.code = c4.spendcategory_code) INNER JOIN company c3 ON c3.code = c4.company_code WHERE s2.code = '37000000' AND c3.is_deleted IS NOT NULL AND s2.is_deleted IS NOT NULL ORDER BY c3.name desc ) a WHERE ROWNUM <= 10) AND (s.code = '37000000' AND c.is_deleted IS NOT NULL AND s.is_deleted IS NOT NULL) ORDER BY c.name desc"</p>

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

I can't reproduce the issue in a test case. Can you help me with that? When I test what you're describing I get the results that are expected.

Comment by Thomas Wahle [ 25/Nov/09 ]

Hi Jon,

if i undestand the last comment correctly this issue will be fixed in 1.2 RC2.

I have reviewed lots of existing test cases but did not find an example where pdo_oci or oracle adapter is used.

Can you please forward the test case you have created for DC-278 to me? I will use this as a template for any further issues and hopefuly reduce your efforts.

Kind regards
Tom

> Jonathan H. Wage updated DC-278:
> --------------------------------
>
> Fix Version/s: 1.2.0-RC2
> (was: 1.2.0-RC1)

Comment by Thomas Wahle [ 10/Dec/09 ]

I do believe that I have found the reason and it is still an issue with Doctrine 1.2.1

Doctrine generate the following subquery which is processed in Doctrine_Query:: getLimitSubquery().

SELECT b.id FROM
(
SELECT a.*, ROWNUM AS doctrine_rownum FROM
(
SELECT DISTINCT i.id, i.lft
FROM item i
INNER JOIN oum o ON i.oum_id = o.id AND (o.is_deleted IS NOT NULL)
INNER JOIN item_type i2 ON i.type_id = i2.id AND (i2.is_deleted IS NOT NULL)
INNER JOIN item_translation i3 ON i.id = i3.id
LEFT JOIN attachment a ON i.id = a.item_id AND (a.is_deleted = 0)
WHERE i.bundling_id = ?
ORDER BY i.lft
) a
) b
WHERE doctrine_rownum BETWEEN 3 AND 4

This function replaces the table alias names. It looks like that the first occurance of "a" is detected and the inner alias for table attachment "a" is replaced by "a2" - that's fine. But also the outer table alias "a" is replaced by "a2" The result will be

SELECT b.id FROM
(
SELECT a.*, ROWNUM AS doctrine_rownum FROM
(
[...]
LEFT JOIN attachment a2 ON i.id = a2.item_id AND (a2.is_deleted = 0)
WHERE i.bundling_id = ?
ORDER BY i.lft
) a2  !!!!!!
) b

„a" is selected but the alias has been changed to „a2" and this will cause an sql error.

It looks like that this bug will only raise if a table is used in the subquery which starts with an "a"

Comment by Thomas Wahle [ 11/Dec/09 ]

As a workaround i have change "a" to "x" in the Doctrine_Connection_Oracle::_createLimitSubquery()

As far as no table in our projekt starts with character "x" this works fine for me.

By the way: Shouldn't it be $this->quoteIdentifier('a') . '.' instead of just a. ??

original code:
$query = 'SELECT b.'.$column.' FROM ( '.
'SELECT a.*, ROWNUM AS doctrine_rownum FROM ( '
. $query . ' ) ' . $this->quoteIdentifier('a') . ' '.
' ) ' . $this->quoteIdentifier('b') . ' '.
'WHERE doctrine_rownum BETWEEN ' . $min . ' AND ' . $max;

modified code:
$query = 'SELECT b.'.$column.' FROM ( '.
'SELECT x.*, ROWNUM AS doctrine_rownum FROM ( '
. $query . ' ) ' . $this->quoteIdentifier('x') . ' '.
' ) ' . $this->quoteIdentifier('b') . ' '.
'WHERE doctrine_rownum BETWEEN ' . $min . ' AND ' . $max;

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

Can you provide the change that fixes the problem for you as a diff so we can test it?

Comment by Thomas Wahle [ 09/Jun/10 ]

Hi Jon,

long time with no hear from you. Hope you are well!

I am sorry, we did not fix this bug really. As writte above we have just implemented a work around by choosing a different character ("x" instead of "a") for the name of the generated sub query alias. This works fine with our data model (no table starts with "x") but may cause the same error with other data models.

At all: There was too much trouble in this project last year. Due to this we made the decision to go ahead with pdo_oci to finish the project in time.

Kind regards
Thomas

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

I'll leave this open if someone runs across the same problem, a test case showing the issue would help with pin pointing the problem area in the code.





[DC-275] Mysql Schema Manager does not correctly detect Decimal + bug fix from me Created: 21/Nov/09  Updated: 25/Nov/09  Resolved: 24/Nov/09

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

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


 Description   

Mysql Schema Manager does not correctly detect Decimal. Lost decimal scale!

bug in file Doctrine/DataDict/Mysql.php

on line 263

 
        if (isset($field['length'])) {
            $length = $field['length'];
            $decimal = '';
        } else {
            $length = strtok('(), ');
            $decimal = strtok('(), ') ? strtok('(), '):null;    // <--- here strtok call 2 times! (line 263)
        }

must be like that

 
        if (isset($field['length'])) {
            $length = $field['length'];
            $decimal = '';
        } else {
            $length = strtok('(), ');
            $decimal = strtok('(), ');
            if ( ! $decimal ) { // or false === $decimal
                $decimal = null;
            }
        }

Please fix it



 Comments   
Comment by Sergei Kuznetsov [ 21/Nov/09 ]

Code formating fix

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

Sorry I don't understand your change at all Can you explain what you're doing? I am confused by this whole block of code:

            $length = strtok('(), ');
            $decimal = strtok('(), ') ? strtok('(), '):null;

Won't that always have the same result? Shouldn't it be..

            $length = null;
            $decimal = null;
Comment by Jonathan H. Wage [ 24/Nov/09 ]

Nevermind after testing that won't work. Can you explain to me what you're change is doing?

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

Ok I think I understand now. Can you comment and confirm what the change is doing.

Comment by Sergei Kuznetsov [ 25/Nov/09 ]

Ok, see:

original code:

$decimal = strtok('(), ') ? strtok('(), '):null;    // <--- here strtok call 2 times! (line 263)

strtok call 2 times and after two call $decimal always === false

fix:

$decimal = strtok('(), '); 

now strtok call 1 times and $decimal have valid value!

and this code check strtok return result

 if ( ! $decimal ) { // or false === $decimal
                $decimal = null;
            } 




[DC-272] levelColumnName for nested sets is ignored Created: 20/Nov/09  Updated: 24/Nov/09  Resolved: 24/Nov/09

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

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

Linux, Oracle 10g



 Description   

Option "levelColumnName" is used to set the name of the level column but the option is ignored

The following code needs to be added in __construct() of Doctrine_Tree_NestedSet

$options['levelColumnName'] = isset($options['levelColumnName']) ? $options['levelColumnName'] : false;



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

This is invalid. The code is not needed and it works fine without it.





[DC-271] Doctrine_Record link many many Created: 20/Nov/09  Updated: 24/Nov/09  Resolved: 24/Nov/09

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

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

php 5.3, win xp sp3/fc4



 Description   

When saving the generated user form of sfGuardDoctrinePlugin 3.0.0 with a related many many object(s), such as groups or permissions, is/are selected, the script dies in Doctrine_Record line 2501 of R6780. Apparently public property access of the relation does not return a Doctrine_Collection object .

Doctrine_Record.php
 
    public function link($alias, $ids, $now = false)
    {
            //... some code
            foreach ($records as $record) {
                if ($this->$alias instanceof Doctrine_Record) {
                    $this->$alias = $record;
                } else {
                    $this->$alias->add($record); //fails here
                }
            }
            //... more code
    }

So I used this workaround as a temporary measure.

ProjectConfiguration.php
 
  public function setup()
  {
    $this->enablePlugins(
      'sfDoctrinePlugin', 
      'sfDoctrineGuardPlugin'
    );
    
    $this->dispatcher->connect('doctrine.filter_model_builder_options', array($this, 'doctrineFilterModelBuilderOptions'));    
  }
  
  public function doctrineFilterModelBuilderOptions(sfEvent $event, $options)
  {
  	$options['baseClassName'] = 'myDoctrineRecord';
  	
    return $options;
  }

Notice that I only changed the access from property access to array access.

myDoctrineRecord.php
 
    public function link($alias, $ids, $now = false)
    {
            //... some code
            foreach ($records as $record) {
                if ($this->$alias instanceof Doctrine_Record) {
                    $this->$alias = $record;
                } else {
                    $this[$alias]->add($record); //works for me
                }
            }
            //... more code
    }


 Comments   
Comment by Colin Darie [ 23/Nov/09 ]

I confirm this issue, and the following line solves it for me too (on a symfony 1.4 project)

Doctrine_Record.php, line 2503
 
$this[$alias]->add($record);
//instead of
$this->$alias->add($record);




[DC-233] Versionable behavior should specify relation alias Created: 16/Nov/09  Updated: 24/Nov/09  Resolved: 24/Nov/09

Status: Closed
Project: Doctrine 1
Component/s: Behaviors, Relations
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
Fix Version/s: 1.2.0

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

Attachments: Text File DC-233.patch     Text File DC-233.v2.patch    

 Description   

I18n behavior sets a nice name for the relation to the translation table, so why Versionable behavior doesn't do the same?

Proposed patch is not only repeats this behavior, but also allows the user to specify custom name for the relation.

See also DC-227.



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

Proposed patch attached.

Comment by Eugene Janusov [ 19/Nov/09 ]

Jonathan,

Why don't you like this change? Regardless of DC-227, the ability to specify relation alias for the versioning table would be useful.

Comment by Eugene Janusov [ 22/Nov/09 ]

Attached version 2 of the patch with hardcoded relation alias.





Generated at Tue Oct 21 09:15:16 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.