all

Length of the i18n column is configurable...

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

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.

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?

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?

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

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.

Thanks for the ticket and fix.

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

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

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.

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.

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.

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.

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

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.

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

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.

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.

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?

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

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.

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.

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?

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.

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.

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'));

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

Patch for the issue.

PHP 5.2.11, Apache 2.2, Ubuntu Linux 9.1

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

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.

Linux, Oracle 10g

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

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>

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.

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)

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"

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;

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

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

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.

Code formating fix

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;

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

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

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;
            } 

Linux, Oracle 10g

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

php 5.3, win xp sp3/fc4

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

 
$this[$alias]->add($record);
//instead of
$this->$alias->add($record);

Proposed patch attached.

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.

Attached version 2 of the patch with hardcoded relation alias.