I have not rigorously tested this patch yet but it has been working for me in what tests I have done so far.

I have posted several very large bugs into jira over the past few months and haven't heard back regarding them. This leads me to believe that the Doctrine team has moved on from Doctrine 1.2.2 and is focusing only on Doctrine 2 issues at this point. I still love version 1 and haven't had the heart (or the time) to migrate my code over to 2 yet. If this is the case then the job of patching bugs like the ones I have reported in 1.2.2 is probably up to us users at this point. As such I will post my patched version of Doctrine_Query in a comment to this bug (My patched version also fixes another bug I reported: DC-594) .

Do you test your changes against our test suite? We will still be releasing bug fix releases, we're just not monitoring and fixing bugs on a day to day basis. As I don't have any help on Doctrine 1 I have to spend a week every 1-2 months just going through issues and closing as many as possible.

I looked at my code again and saw some very glaring errors in it (I was rushing through bugs and as soon as I thought I had fixed this one I didn't take the time to read it over – in the future will be sure to use the tests in order to avoid any such oversights).

At any rate I have changed my patch to the code and this is both working for my needs and passing all the tests again. Here is the newest version of my patched code:

I tried using winmerge to make a patch file but it seems contain both the entire before and after files in it. I am not sure if I am doing something wrong with the software or if this is just what a patch file looks like.

I was able to generate a patch. It had some errors in our test suite but I fixed them. Since we don't have a test case for it I am not sure if the changes I made affected anything for you. Can you test the patch or provide a test case?

I checked out the svn branch 1.2.2 and noticed that you had my original/broken patch in the code (that one failed some tests for me so I fixed it and tried to upload it in the last patch file I attached to this thread – the patch file that didn't work).

Using the technique you described I made a working patch to put the correct version of my code into the 1.2.2 branch.

I have run into a very problematic Doctrine 1.2.2 bug which puts me in quite a bit of danger of having to rewrite my whole app in Doctrine 2 (hopefully if this is a bug it isn't present in Doctrine 2).

The problem I am running into seems like something that probably would have been found and rectified however so hopefully there is something wrong in my execution.

The problem I am running into is caused when I have a combination of the following 3 things in my query:
1) A group by field referencing a table in a relation
2) A join to a different table via a many type relation
3) A limit clause

This combination causes Doctrine to create a broken SQL query which it then throws an exception about when I try to execute the query or call getSqlQuery() on it.

Using some sample data I put together some very simple examples to illustrate the problem:

As you can see from the SQL in the exception Doctrine is trying to create a query that groups by a field from the Zip table with out first joining to it (SELECT DISTINCT c2.customer_id FROM customers c2 GROUP BY z2.city LIMIT 5).

I know Doctrine works some magic to get limit statements to work with joins and I suspect that something with in that magic may be broken, but hopefully its something I am doing wrong.

Take out any one of the 3 things I mentioned I above and everything works fine – the following all work:

Its also worth noting that the following changes also stop the problem from happening:
Changing the relation to the Order table to be a one relation instead of a many relation.
Changing the group by to a field located in the "from" table (such as: $q->addGroupBy('Customer.customer_id')

I took a look at the doctrine 1.2.2 code to try to track down what was causing this bug and I think I have found and fixed it in my copy of the code base.

The problem is on line 1459 of Doctrine_Query and looks like it was just an oversight. The code was checking if it should preserve left joins while generating the subquery based on whether or not there were any orderBys, wheres, or havings added to the query. I changed the code to also watch for groupBys and it seems to have resolved this issue.

I wanted to give you guys a heads-up about a fairly critical missing line of code from the "Getting Started" docs... From what i can tell, the

spl_autoload_register(array('Doctrine_Core', 'modelsAutoload'));

statement is not mentioned anywhere in the docs and for beginners (like myself) who start to experiment with creating tables from YAML schemas, this is a dead-end since the models do not load and hence no tables are generated (without a warning i might add).

After some fierce Googling, i managed to find that critical line of code, popped it in and Bob's my father's brother... For newbies i fear that this might be a dealbreaker.
Thanks

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.

I'm experiencing the same issue with 4 connections. The I18n behavior is almost unusable for models whose connection is not the last one defined. I searched for an acceptable solution but I haven't found one (IMHO the setting to the right connection before each query is not acceptable in large projects). I tried to do like in Search behavior, but it didn't work, I doesn't know enough doctrine internals to understand why.

I've just now battled with the very same problem in Doctrine 1.2 (the version bundled with symfony 1.4) and the problem seems to be caused by the fact that Doctrine_Record_Generator simply isn't written such that it is able to reinitialize generators for unloaded table instances after a connection is closed. This problem also manifests itself after a table has been loaded in a connection and one tries retrieve a table again after Doctrine_Connection->evictTables() has been called. This makes it impossible to to open more than one connection at a time in a request/script when using behaviors that dynamically modify table instances (such as the i18n behavior). The issue states that this has been fixed but I looked at the latest code and the problem still seems to be very much the same.

Doctrine_Record_Generator determines if it needs to run its initialization methods simply by checking if the to-be generated class, as defined by the className option, exists using a class_exists call. This means that the first time this method is called the initialization happens but for every subsequent call no initialization is made. Now, in the i18m behavior, the important initialization happens in its setTableDefinition method in which it removes any of the translated fields from the table instance that is been setup and redefines them as relations on the to-be-created Translation class. It then finishes off by dynamically declaring the new class for the translation record using its generateClassFromTable method.

Thus, the first time everything goes smoothly and the i18n generator's setTableDefinition is called and the table instance is properly initialized. Everything will now work as expected while the current connection is open since the connection instance keeps the i18n modified table instances alive and well for callers.

But, when the current connection is closed the i18n modified table instances it holds are also removed (goes out of scope). Then, when a new connection is opened, this new connection will start without having any table instances. This means that the next time one asks the new connection for a table instance of the same class with the i18n behavior the i18n behaviors will fail to initialize because the generator at this time believes its class has actually been initialized which, in turn, means that the table using the i18n behavior isn't properly initialized. No initialization means that this table will now include the non-existant i18n fields in the select part of its queries (those are in the translation table) causing those queries to fail miserably.

I believe this could be fixed by adding a static attribute to Doctrine_Record_Generator that tracks the spl_object_hash of the underlying dbh instance variable of the doctrine connection of the table parameter. If the hash is the same the next time that the initialize method is called the generator can decide not to reinitialize itself but if it detects that the hash of the current connection is different then that is definitely a clue to the generator that it needs to reinitialize itself (i.e. run all of the initialization methods but generateClassFromTable which should't be called more than once).

Maybe do it like this perhaps:

abstract class Doctrine_Record_Generator extends Doctrine_Record_Abstract
{
public function initialize(Doctrine_Table $table)
{
/* ... */
$currentConnectionHash = spl_object_hash($table->getConnection()->getDbh());
//Next part is called if this is the first connection made or if this is a new open connection with new table instances
if ($currentConnectionHash != self::$lastConnectionHash)
{
self::$lastConnectionHash = $currentConnectionHash;
$this->buildTable();
$fk = $this->buildForeignKeys($this->_options['table']);
$this->_table->setColumns($fk);
$this->buildRelation();
$this->setTableDefinition();
$this->setUp();
if ($this->_options['generateFiles'] === false && class_exists($this->_options['className'])) {
$this->generateClassFromTable($this->_table); //Don't generate the class more than once ever
}
$this->buildChildDefinitions();
$this->_table->initIdentifier();
}
}
}

I'm also experiencing this issue, using the stable version of Symfony 1.4.13. If I define multiple database connections, the i18n Translation relations fail with this call: Doctrine_Relation_Parser->getRelation('Translation', )

I tried to implement the suggest above (ie adding a static hash of the database handle to the Doctrine_Record_Generator class file, which does clear out the connections. However, I then have difficulty with Doctrine recognizing CategoryTranslation as a class:

"( ! ) Fatal error: Class 'CategoryTranslation' not found in /sitename/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Table.php on line 545"

I don't think this is something that can be "fixed". the DateTime object uses strtotime() and is mssql provides a date it doesn't understand, we can't do much about it. I think you need to configure your mssql server to return a date format that php can parse properly.

I don't want to be working with Mssql (who would?). I can't change the database or the configuration of the database, other systems rely on the stuff.

There are some serious problems with trying to use Doctrine with MsSQL. PDO for mssql (pdo_dblib) doesn't let you indicate columns more then 30 characters. With the aliasing of columns scheme some columns in my tables go over that and Doctrine thinks it needs to hydrate all of the objects I return because it sees a null (pragmatic: I didn't trace the code to find that, only trial and error). And now it looks like I'll have to keep the modification I made to the code to work with dates (which means I will without exception run into further problems) .

I suppose I'll have to crawl back to my propel code base. With the no real composite key support and no interest in supporting MsSQL I'll have a hard time explaining the choice to anyone else in my group.

Awesome tool if I'm building something out of the box and I can design the environment for it's needs. Too many problems if you have to wrap it around something existing. Good luck! I look forward to future releases. Thank you for your responses!

In response to your need for a mssql server: I have a clustered environment that I have to work with. If I can do any testing please let me know. I would very much like to contribute to Doctrine's success.

If I make changes to the properties of an instance of a record but don't persist them (so the record's dirty), then in a separate process hydrate another record instance, the original record instance's properties are altered.

I'm not aware of all the instances in which this happens, but it definitely occurs when finding records through a DQL query or loading related records.

This is particularly troublesome since we're experiencing the loading of one record affecting another instance thousands of lines of code away. It seems like the records are shared somehow. This occurs without any caching of any kind.

This is unfortunately the default behavior of Doctrine 1.x. Because of backwards compatibility this default behavior can not be easily changed. However, some time ago a new attribute was introduced: Doctrine::ATTR_HYDRATE_OVERWRITE. You can set this to FALSE which does what you want I think. Doctrine 2 already behaves this way by default.

Ah, fab. Sounds like what I need! Missed it in the docs, sorry. Is there a list somewhere of all the settings and what they do? That would be handy if not, since they seem to be dotted around the manual at the moment so they're easy to miss. Are there any other side effects I should be expecting if I turn that setting on? Thanks!

I dont think any such list exists. As you said all of the attributes are spread throughout the documentation. You can create an issue as an enhancement request for the documentation for that.

Setting that attribute to false should have no other side effects. It really only affects hydration and controls whether the values from the database or the local values should be considered "newer" and therefore kept around.

I will close this issue. If the attribute does not solve your issue, please let us know.

If we remove "AS joe" part from the query, it gives the correct result. I noticed that with this alias, Doctrine forgets to retrieve the primary key of the servant row and this produces an invalid UPDATE query. There are two possible ways to retrieve this:

1. Use the data from the "Master" row, as we fetch everything, including the ID of the servant row. Doctrine knows about the relationship and potentially can use it.

It actually is logical but I absolutely understand why it looks illogical to you.

Doctrine 1.x auto-adds the primary key only if it is needed. It is needed only if the hydration mode is record/array and any non-scalar value is selected. If neither the hydration mode requires the primary key, nor the selected result expressions contains object fields (not object fields selected as scalar values, i.e. what AS .. does) then it is not added.

"select x.foo as something" only selects a scalar value. The fact that makes this so confusing is that scalar values are put into Record objects in Doctrine 1.x, so to you it looks like a full object was hydrated when in fact it was just a scalar value.

in Doctrine 1.x this is unfortunate but expected behavior. In Doctrine 2 this confusion will not arise as there is a clear separation and scalar values are never put into objects.

Roman S. Borschel - so if it is not a "real" record but only a "plain" record with a scalar value, why doctrine tries to use it for save? I'm not sure about the internals of this process but something must be wrong there

OKOK, so now try new testcase (attachment 9999b):
I have checked it and this issue is not only related to MySQL and InnoDB. This testcase fails with this error:Doctrine_Ticket_9999b_TestCase : method testTest failed on line 72 SQLSTATE[23000]: Integrity constraint violation: 19 ticket_9999b__master.servant_id may not be NULL

So now let's try this without notnull constraint on "servant_id" (testcase 9999c):
It works ok, no error on saving. But now let's retrieve that record from DB:

because it is broken by design. Whoever made the decision to put scalar values into record objects (I think it was Konsta) did not think that through. Doctrine itself does not make a distinction internally between "real" records and "records with only scalars". Hence why it pukes on save(). I just dont see a good way to fix this without significant work and breaking existing code. If you have an idea I am all ears. If we start to add the primary key even if only scalar values are selected of a class we start to make all kinds of queries impossible that compute aggregate values.

In 1.2 I fixed this by removing the hydration of aggregate values in to the relationship record. This was something that was built by design in 1.0, we realized it was not good so in 1.1 I made it so the aggregate values ALSO went in to the root component, and I deprecated the use of the value from the relationship. So now, in 1.2 we can remove it. I committed your test case and it passes now with this changeset.

This O patch caches the information needed to call the listeners and calls the listeners in reverse order after all the data has been loaded. The net effect is that postHydrate listeners are called for all an object's children before being called for a parent object.

Memory cost should be minor (O @ two pointers per record), and the (additional) processing cost should be flat and almost zero (n function calls to postHydrate have simply been moved outside the loop to a second loop). There is an additional call to $table->getComponentName() in the second loop that could be eliminated by storing $componentName with the other event initializers in the new stack).

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, ...

And this code dies with an error:
Doctrine_Connection_Pgsql_Exception: SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "as" LINE 1: SELECT (1 <= LOCATE("p"."host", $1) as is_host_matched) AS "... ^. Failing Query: "SELECT (1 <= LOCATE("p"."host", ?) as is_host_matched) AS "p__0" FROM "portal" "p"" in /web/vendor/symfony/1.4-svn/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Connection.php on line 1082

In PgSQL you can use POSITION for this needs (I want to mention, MySQL has this function too as an alias for LOCATE)

I have same problem on a postgresql table, 1 out of 10 in the schema. The table has 6 primary foreign keys and a single autoincrementing primary integer key, 'id', column. 'id' is unavailable after a save(). I'm getting around this with a search for the inserted record, but it's a slow PITA.

Doctrine seems to be adding DISTINCT to SQL queries without any good reason (to the table's primary key!) and thus SERIOUSLY HURTS performance. It even seems like Doctrine adds a whole new DISTINCT query without a good reason. I believe the extra query is the result of the different implementation of LIMIT in Doctrine vs. SQL. However, when a unique index is involved, this extra query seems redundant.

In the following example, execution time went from ~5sec down to ~1sec when I simply removed the DISTINCT added by Doctrine.

Why is the extra query created anyway?Is there any way to prevent Doctrine to add the DISTINCT part when there's a unique index on the column?

But when adding a limit() condition like:
$query->limit(20);
$query->execute();

The SQL generated query is not valid. There is a problem with the alias used in the NOT IN subquery. This query is generated like this:
WHERE c2.id NOT IN (SELECT e2.contact_id AS e2__contact_id FROM email e)
There is a mix between alias e2 and e

I have been trying to debug, but I didn't understand what was going wrong. The problem seems to happend in the class Doctrine_Query between line 1486 and 1554, but this part is obscur to me.

Things are going wrong in the unserialization. In this test script, I manage to create two objects holding the same oid, but pointing at different object instances (but for the same database id). The output of this script after running it twice shows me:

Looking at the unserialize() code in Doctrine_Record, the problem seems to be coming from two issues in there:

$this->_oid is generated before the data unserialization. Because of this, the generated $this->_oid is overwritten with whatever was in the serialized data (this is why in above example, the oid became 5 for the unserialized record)

The unserialized record is not added to the table's identitymap, making it kind of invisible for the table's getRecord() code, resulting in two different objects that both represent the entity with id = 4 (as you can see in the "24 versus 23" output).

See the attached patch for a fix that I did on our code tree to make the test work.

Note that I added some extra code in the unserialize method to cleanup any existing entitymap and table repository entry for the unserialized object. This is of course not the best route, but it helps with some unit testing code where a lot of serialize/unserialize handling is going on and objects got mixed up when not doing this cleanup.
IMO, better would be to add an unserialization method to the Doctrine_Table, which would, like find(), act as a factory for turning unserialized record data into a Doctrine_Record object, possibly making use of already loaded entities that are available in the table's internal caches. With unserialize being handled directly from the Doctrine_Record, there is no way AFAICS to keep up the rule of always having exactly one object in a scope that represents a certain object in the database.

When running above script with this patch applied and with removing the $a, $b and $c assignments (just for making the oid's different between the two script runs), we get the following output:

So here, unserializing an object and then reloading the object through the table object gives use two times the same object, representing db object with id = 4;

When doing things in a different order, we still can force an issue, but this is due to the things mentioned above: to cleanly handle this, unserialization should be handled from a factory method on Table. This script shows the behavior:

FYI: we removed the "Remove existing record from the repository and table entity map" code from our patch. We had some issues with unit testing without this bit, but we updated the unit tests to work without this bit of code. The "Add the unserialized record to repository and entity map' part stays of course. I think you can ignore the cleanup code in the patch. As long as scripts unserialize data before working with it, things should be fine without it.

Trying to always use the same object for the same entity in the database, we came up with a factory method that we put on our record class as a static public. Maybe this is an idea that you want to include in Doctrine as well?

staticpublic function fromSerialized($serialized)
{
$entity = unserialize($serialized);
if (!($entity instanceof Doctrine_Record)) thrownew Exception(
__METHOD__ . ': serialized object is not a Doctrine_Record object'
);
// If the unserialized object is a persisted entity, then we must
// check if there is already an object for that entity available in
// Doctrine's table repository.
if ($entity->exists())
{
// Retrieve the entity through the table repository.
$table = $entity->getTable();
$repository_entity = $table->find($entity->id);
// If a different object was returned than our unserialized
// object, then there was an object loaded before unserialization.
// We will merge the data from the unserialized object with
// the existing object and return the existing object to the caller.
if ($entity->getOid() !== $repository_entity->getOid()) {
$repository_entity->merge($entity);
$entity = $repository_entity;
}
}
return $entity;
}

For us, it's working wonders in combination with above Doctrine_Record::unserialize() patch. When letting this code handle our unserialization, the same object (checked by its oid) is used for referencing the same entity throughout the code. We call the code like this:

The loading of models fails on Centos 5 systems because loadModels() relies on RecursiveDirectoryIterator which seems to return filenames in different orders on different operating systems (see this older doctrine bug: http://trac.doctrine-project.org/ticket/1688 ).

The result is that Doctrine tries to load the model class before it's base class which fails because the base-class is not yet known at that time.

The aggressive model loading can only be used if you handle the dependencies between classes yourself or you don't have any dependencies and it is no problem to aggressively require all files it finds in a directory. It sounds like you need to use conservative or pear style model loading.

I discovered this whilst trying out migrations via symfony. I added a datetime field to my schema.yml and generated the migrations, but upon running the migration I got the following error:

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '()' at line 1. Failing Query: "ALTER TABLE order_item ADD purchased_at datetime()"

Ok, I might have been being dumb here. I've just checked the doctrine documentation for defining the schema (http://www.doctrine-project.org/documentation/manual/1_2/en/defining-models) and there's no mention of a datetime or text field (I've just realised that I should have used string instead of text anyway), but datetime still works as a column type so shouldn't it be documented?

Your ticket is hard to read, just for future reference it would be wise to make sure the issue is readable for us. Anyways, I had a look and your schema is incorrect. You have a foreign key but it is also set as primary and auto increment.

Sorry for the unreadable ticket, I tryed to make it understadable as much as I can.

The thing with the foreign key and primary key is that we have a existing database and want to port it to Doctrine.
In the database the structure is like that and in the documentation I didn't see anything that say that this won't work. Can you point me to some aditional information?

I'm working on an open source application, Sahana Agasti (http://sahanafoundation.org/), using Symfony 1.4 as the framework and Doctrine as the ORM. This project stumble into a similar issue with establishing a direct 1:1 relationships on primary keys. Below is an example of a person and person's date of birth table. In the yml file, Person has an id field as the primary key. This field is referenced by the primary key field person_id in PersonDateOfBirth. However, Doctrine only creates the tables and not the relationship between the two tables correctly.

Your test case has some errors in it. The ->Phonenumber relationship is a many so it is a Doctrine_Collection. Also, this is all expected behavior for aggregates to be located in the root. They only exist in the relationship as well for BC reasons. The whole functionality is flawed a bit and can't be patched without breaking backwards compatibility. All these issues have been thought through and addressed in Doctrine 2

If you want to add a behavior to a behavior, you (depending on your template) can get an error message telling you, that the _table property is not an object.

This happens, as actAs() method of Record_Abstract does first the $tpl->setUp() call and then the $tpl->setTableDefnition(), as for the cascading templates - which are using Record_Generator - the $child->setTableDefinition() is called before $child->setUp() in method buildChildDefinitions(). Switching those two lines fixes the error and has, as far we can see (having it in our production system for quite a while now) no side effects besides fixing the error.

Hi, when providing feedback and you have a change, it is best to provide a patch. Can you generate a patch for your changes and attach it to the ticket?

However, if I understand your verbal description of the change correctly, it is not right. We can't call setUp() first, because setTableDefinition() is supposed to be called first. This is how it is supposed to work.

In Doctrine_Parser::doLoad() the fixtures are included which will try to execute the file with the php-interpreter resulting in all unescapted code which starts with <? (if shorttags are on) or <?php being executed (as long as it is in one line and ends with ?>).
As long as the php-code is multi-lined the break after <? or <?php gets converted to \r\n which will create a parse-error and make it impossible to import the fixture:

I think this is somewhat expected. As I have stressed in the past. Dumping data fixtures from the database can never work 100%. The idea is that you dump to get started, then modify the dumped fixtures so that they will re-import properly. If you have a suggested fix/patch please feel free to share and re-open.

I modified the doLoad() function to not use include but file_get_contents and the import of some critical fields (which contained xml data as well as raw php data) worked fine.

But honestly, I've got the feeling that I haven't really understood why the yaml load is done via including the file and saving the output buffer - so maybe I'm missing the big picture.
My altered version of the doLoad function looks like this:

This issue is a lot like the bug with refreshRelated() in ticket #DC-93. Calling save() on a record will cause hasOne rows to be generated in error (with all NULL values). It looks the saveRelatedLocalKeys function checks for foreign keys, calls isModified, which returns true, and calls save on that related object. isModified is returning true for a row that doesn't exist.

Hi, this patch is not valid. We can't only save records that already exist. That means it stops all new records from being saved. If you want to help fix this, first we'll need a reproducible test case. Thanks, Jon

I created a patch for this bug, which extends quoteIdentifer() method in connection to detect comma separated fields and escape them separately. It also supports any amount of fields (not just two). It's done in this method, and not in getIndexFieldDeclarationList() in export classes, because it would require a major refactoring for a lot of classes and methods inside different classes. Please review this issue, so I can commit.

Hmm. After looking at this, it doesn't seem right. The method getIndexFieldDeclarationList() is already implemented this way and each field is quoted individually. Let me see your schema where you define the index..

Ok, it might have been not right, but I made it like this, because this data was tunelling from definition to getIndexFieldDeclarationList() and at that point fields are already as list (comma separated), so I guess my fix worked more like a hack.

This part is wrong. the comma separated list of fields is not supported and Doctrine doesn't support composite foreign keys. So it is a problem with the importer for the database you're using. Is it mssql?

When you use the Doctrine_Search_Analyzer_Standard all special characters like "ü" are removed or converted to e.g. "ue". So far so good.. The problem arises when a user performs a search.
Since Doctrine is using the plain query with the special char "ü" instead of converting it also there no results are returned.

Using the UTF8 analyzer is no option because often the normalization is a desired feature. It allows for example a user to formulate the query either as "Muenchen" or "München" and he still receives a relevant result.

I don't think that that's a good idea since it breaks the UTF8 analyzer. I would refactor the analyzers to include a method like normalize(). Those methods could then be called in the analyzers analyze() method.

This would then also allow to remove some code duplication in the analyze() method. It could be changed to the following code in Doctrine_Search_Analyzer_Standard and could be completely removed in Doctrine_Search_Analyzer_Utf8:

At first this seems like a good solution but I realized it will break things even more. We allow wildcards and certain keywords in the query string. *, OR, AND, etc. If we were to run the normalize() method on the query text it would break all that functionality.

Doctrine_Search provides a query language similar to Apache Lucene. The Doctrine_Search_Query converts human readable, easy-to-construct search queries to their complex DQL equivalents which are then converted to SQL like normal.

So I would rather break those special things than to have the search missing existing items. But maybe there's a better place to call that normalize() - perhaps where the query is analyzed and converted to a DQL statement. It should be possible there to run normalize on every search term.

It looks like EntityManager's clear() method doesn't remove objects that was persisted during script execution.

Bellows are two functions. First one insert 10.000 records and use clear after each flush that should remove objects from memory, but instead of that memory usage growths in each iteration. There isn't any other reference for this objects.

I've checked how it works for reading and with clearing it works perfectly - script uses only constant memory.

I needed a way to allow my queries to figure out what connection to use based on what table was used in the from. In other words I needed my queries to be able to run on the same connection that the table in the from used, but the way my code is structured I didn't have a convenient way to do this outside of doctrine.

I built a feature into doctrine for this I called: autodetectConnection.

I will post the patch for this after I build a test case for this ticket.

Upon trying to make the test cases for this I looked into the feature I had added further and found that it seems as though doctrine has this ability already. I suspect my addition of this feature was in response to a bug I had which I have since fixed.

In my proyect I have a table called OrigenesOportunidadCliente, which id field name is idOrigenOportunidadCliente. As you have probably noticed, the name contains Or: idOrigenOportunidadCliente. And there is where it fails, it gets as if there where an OR statement, not finding a valid field name in the below foreach as the field is "OrigenOportunidad".

The promplem is, that the same query on the same models produce diffrent results. In some cases not all columns from database table are present in genereted sql query. For example: we have three columns ID, TITLE, NAME. But doctrine generates query like "SELECT t.id AS t_id, t.title AS t_title FROM..." ignoring NAME column. I tried manually add "->select( * )" in method find(line 1616 of file Table.php), and this resolves problem.

I want to bookmark ads on my site. So i have Ads table, users table (sfDoctrineGuard) and a refclass Bookmarks. I've created an ajax link to an action, where i retrieved $ad object, $user_id and
$ad->link('Bookmarks', $user_id, true);
So I expected a record in a database to be created.

$rel->getTable()->getIdentifier() returned me an array('user_id', 'ad_id') instead of a string. So the query which was generated looked like
UPDATE bookmarks SET ad_id = ? WHERE (Array IN )
And Array is not the name of a column.

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/

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

I ran into and patched another bug in Doctrine 1.2.2 (The menu in jija shows 1.2.3 as released but I am not seeing it in SVN or on the web site so I can't test the bug in that version).

When you include a dot in a string in your select statement the function getExpressionOwner in Doctrine_Query fires and considers that the text appearing before the dot in the string is the name of a class. There for it attempts to extract a short alias out of it.

I think I found a work around for you – I tested this bug out to see if I could recreate and patch it and found that my own system didn't generate the bug. Turns out the difference is my code encapes the strings that go in the query with single quotes and this seems to solve the problem.

Try the same query you posted above but replace the "%.net%" with '%.net%'.

I do think this is still a bug – I there are some problems with double quotes in dql in general I believe. Then again there may be something in the docs about this being a restriction that I overlooked (not sure).

But since its solvable with using single quotes I would recommend putting it as a low priority bug – which may mean it won't actually get fixed any time soon. Whether it gets fixed or not though its good to have these kinds of bugs in the system so that there is a record of everything that needs fixing and so other users can find work arounds to there problems by looking through the archive.

I'm curious if this could be the same issue that causes doctrine:build-schema to give either the 'Missing class name' or 'Couldn't find class Content ' error? I am going a little crazy trying to figure out why doctrine:build-schema doesn't work for me. Details here:

I did a quick glance at your issue. I have never encountered this error my self and I don't think it is related to my issue.

When I have a bug like that the first place I start looking is where the exception is being thrown.

For you its in the Doctrine_Import_Builder class on either line 949 or 995

You could start by putting some debugging to see what the $definition var is. That may offer some insights. Then if that doesn't clarify whats wrong with your schema you could start back tracking out of the method to see where else things could be screwing up .

The getTagIds will not match tags in a case insensitive manner however MySQL unique indexes are case insensitive.

getTagIds('Foo') will create a new tag even if the tag 'foo' exists in the database, when trying to insert the tag 'Foo' you will get a MySQL duplicate key error.

I have written a new version of the function that handles this, it will not modify the case of new tags only match in a case insensitive manner for current tags (I know that is not 100% clear, wording sucks sorry about that). Oh and I think this function might be every so slightly faster but not sure on that one

I developed the entire project under Windows Xp, IIS 5, php 5 and Mysql 5; everything worked fine until I copied the project into a Ubuntu environment as the production system and the problems began...

"Fatal error: Class 'Agencia' not found in /funciones/busq.php on line 165"

In Doctrine_Export_Pgsql the table name of query like "ALTER TABLE mytable ..." are not quoted even if ATTR_QUOTE_IDENTIFIER is enabled.
This create failing queries, for example if the table to alter is called 'user'.

Please note in Mysql exporter the table name of ALTER TABLE queries is correctly quoted.

SELECT fields, t.typtype AS typtype FROM information_schema.columns WHERE ..

and the t relation is not specified. By the way, commenting out the typtype, the string length is no more detected.
I think there is something wrong around line 170 - the "type" column should contain "varchar", not "character varying".

I proposed you a patch, I tested it before sending it back to you.
You applied something else to Doctrine source code that is not working. Try to copy and paste the query in http://svn.doctrine-project.org/tags/1.2.3/lib/Doctrine/Import/Pgsql.php (listTableColumns) to pgadmin and execute it. The postgres server will refuse to execute that query.
The error is due to a call to a "t" relation, which is not declared in the FROM (the query is something like: "SELECT a.field, ..., t.field FROM a").

Ok.. this is complete mess, somebody with permissions should reopen it.
This one works for Francesco as he is running with notices disabled.
if ttype is removed or commented out , then you get a notices that ttype key doesn't exist.
and it seems that ttype is required for enums to work.

in one of the comments Ricardo suggested replacing ...
t.typtype AS typtype with
(SELECT t.typtype FROM pg_type t WHERE t.typname = udt_name) AS typtype,

adding this get's rid of notices, but i don't know what happens for other things mentioned within comments of if this is a correct fix... The one who provided support for enums should take a look

I think Francesco should run import with notices enabled and then add the upper sub-query to get rid f them.. then it should also test if the rest of the import still works correctly.

I've discovered a variation of the problem tested in tests/Validator/ForeignKeysTestCase.php. This happens when you synchronizeWithArray and a foreign relation is set - isValid will trigger the isnull validator.

This is probably better explained through two new test cases. I've included them below. The first test case passes. However, the second test case (testSynchronizedForeignKeyIsValidIfForeignRelationIsSet) fails.

I think this has to do with the inconsistencies in whether get should create a real relation or fake it until it's actually set with a setter. From what I can tell, this all stems from the support for the following behavior:

$address = new Address();
$address->Person->first_name = "Bob";

This behavior is taken advantage of from within synchronizeWithArray:

$this->$key->synchronizeWithArray($value);

However, because it doesn't create a real relation this way - the original issue comes up. Updating record's get to create a real relation requires us to update Doctrine_Record's _get to use coreSetRelated (instead of directly modifying $this->_references). However, doing this will conflict directly with test Ticket 1072.

I'm trying to get migrations going, such that I install the database, make a change to the schema.yml (something simple such as a column length change), and then have a migration generated and performed.

No matter what I try, doctrine just generates an initial add all the database tables, then after that if I try any further migration generation, they all try to drop all the database tables. I am not having much luck.

I have an Issue model with one owner User (relation Owner). I have this code:

$issue->link( 'Owner', array( $owner_id ) );

At the time of calling this code, the $issue->Owner is null. When this is called, the link fails to assign the new owner to the relation. I've tried to hotfix it changing line around 2516 in Record.php:

$this->get($alias)->add($record);

to this:

if( $c = $this->get($alias) )

{
$c->add($record);
}

else

{
$this->set( $alias, $record );
}

In this case the $this->get($alias) returns NULL, so the subsequent add($record) fails.

If I change the order passed to createTablesFromArray to Model_ProductFeature, Model_Product, Model_Feature, the problem goes away.

So there is a problem with a dependency on the order that the loaded models that are passed. I will try to investigate further in the future, but have now resorted to naming the refClass to Model_AProductFeature instead.

But the BuildAll tasks is executing three tasks including one which is regenerating the models. ( from the constructor )
$this->models = new Doctrine_Task_GenerateModelsYaml($this->dispatcher);
$this->createDb = new Doctrine_Task_CreateDb($this->dispatcher);
$this->tables = new Doctrine_Task_CreateTables($this->dispatcher);

My suggestion is to replace the build-all in the rebuild-db task with just the following. This would make more sense.

This does not make sense, it implies strict type checking is always done for integers.
I think the first check (line 1533) should be done loosely so that a string '123' is equal to integer 123, and thereby such a field is not considered modified.

Oh no, I misunderstood the DC-550. In fact the problem was introduce when fixing the 550. The strict type checking is a regression that have been introduce in the 550. Before the values old and new were cast to int.

This regression can be a real problem. With this, if we set an integer value to a record, then the record is set as modified even if the value was the same as before.
Here is a little test case to demonstrate the problem:

I had a model named 'Page' that didn't behave decently. It would only save when a certain field ('h1') was changed, if other values where changed the record wouldn't save the data but not notify me at all. Also the SoftDelete didn't work, probably because the same thing. Var_dumping the $page->toArray(); just showed logical data. Echoing the $this->deleted_at on postDelete() showed a correct DateTime (mysql), though directly after the $page->delete(); the value of $page->deleted; was NULL.

Recreating this same wrong-doing (avoid the word Bug) I cuold not, because a simple testscenario resulted in correct behaviour. However when I altered the name of the (non-base) class from 'Page' to 'Sitepage' it all worked.

This description is probably too indescriptive to extrapolate the actual cause for the wrong-doing in my scenario, but now, if some else runs into the same odd inexplicablications .. I've found me a friend

When MSSQL receives even just a default value of null it still creates a default constraint. Said constraint prevents doctrine from removing the deleted_at field in migrations (due to the dependency on the constraint).

I have no machine to test the effects of this on MySQL. I would imagine that it would not materially affect MySQL as the default values are never used anyways (hence the default value of null).

Attached is a patch to fix the behavior (for rev 7544 in /branches/1.2)

—

If one is running into problems with migrations being unable to move backwards due to default constraints on SoftDelete columns, one can run the following T-SQL script to remove all default value constraints from a database (EVEN THOSE YOU SET MANUALLY, USE WITH CAUTION):

This is related to an issue I reported a month or so ago - http://www.doctrine-project.org/jira/browse/DC-584. A solution I proposed there was to allow Doctrine to name constraints so they can be referenced and dropped later. If that were in place, the SoftDelete behaviour could manage the constraint itself?

Craig, It maybe would if Doctrine were creating the default constraints itself. If Doctrine doesn't handle the default constraints then naming has no effect as MSSQL will silently create said constraint.

And now that I think of it, this issue is going to crop up any and every time you use default values in MSSQL. Perhaps it would be best to consider this ticket more of a cleanup (the behavior isn't using default values so there's no point in creating the constraint anyways) and side effect of the problems listed in DC-584 which should be the primary focus.

Joins are not supported on update and delete queries because it is not supported on all dbms. It won't be implemented in Doctrine 1 or Doctrine 2. You can however get the same affect by using subqueries.

I use Zend autoloader with Doctrine and everything works fine,
until Doctrine_Import_Builder::emitAssign() is called (e.g. with Taggable Extension).

I get autoloader Warning: include_once(Doctrine\Template\Doctrine\Template\TaggableTag.php) failed to open stream
Since class_exists with true parameter automatically tries to autoload the class with wrong name.