[DC-1050] Doctrine_Relation_ForeignKey ignores ATTR_COLL_KEY attribute Created: 06/Mar/12 Updated: 07/Mar/12 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Attributes, Relations |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Uli Hecht | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Windows 7 64Bit |
||
| Attachments: |
|
| Description |
|
Doctrine_Relation_ForeignKey::fetchRelatedFor() executes the following code at line 70: $coll = $this->getTable() As you can see it accesses the first element by using index "0" in $coll and hence ignores a modified ATTR_COLL_KEY-setting, for instance: $this->setAttribute(Doctrine_Core::ATTR_COLL_KEY, 'id'); Fortunately I had two models (ForeignA and ForeignB) in my project which both have an one-to-one relation to a third model (Main). That helped me finding this bug which causes the following strange behavior: // program 1: $m = new Main(); // program 2: $m = Doctrine_Core::getTable('M1')->findOneBy('name', 'M1'); ------------------------- The big problem about this issue is that behavior is inconsistent. If you don't split the example above into two separate programs/processes you won't have problems, since Doctrine accesses the reference which was stored when calling save(). You will get into trouble using functional tests in Symfony. Since there is only a single process for all requests I wasn't able to reproduce a problem caused by this bug which appeared in the production environment. ------------------------- Edit: Doctrine_Connection::queryOne() is affected as well! A solution is to replace $coll = $this->getTable() by $related = $this->getTable() |
| Comments |
| Comment by Uli Hecht [ 07/Mar/12 ] |
|
Suggested patch |
[DC-1048] MSSQL Connection Created: 16/Jan/12 Updated: 16/Jan/12 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Connection |
| Affects Version/s: | 1.2.4 |
| Fix Version/s: | 1.2.4 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Constantine Tkachenko | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Microsoft Windows Server 2008 R2; IIS 7; PHP 2.3.8; Doctrine 1.2.4; Symfony 1.4.16 |
||
| Description |
|
Function spliti(); is deprecated. $field_array = str_ireplace(' as ', ' as ', $field_array); thnx. |
[DC-1046] Connection MSSQL replaceBoundParamsWithInlineValuesInQuery Created: 15/Dec/11 Updated: 15/Dec/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Peter Eisenberg | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Revision: 104 |
||
| Attachments: |
|
| Description |
|
Hello, We found a bug in Doctrine1 MSSQL Connection. Please find the patch for it, I hope it helps to you as well. Kind regards |
| Comments |
| Comment by Peter Eisenberg [ 15/Dec/11 ] |
|
Small changes: please use the following instead of the original: another case you got the following error: Use of undefined constant xxx - assumed xxx. Kind regards, |
[DC-944] Precedence problem in SQL generation allows bypass of pending joins Created: 03/Dec/10 Updated: 10/Dec/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Query |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Walter Hop | Assignee: | Guilherme Blanco |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
PHP 5.2, 5.3 |
||
| Attachments: |
|
| Description |
|
'Pending join conditions' are used by listeners to inject extra SQL conditions into a query. They are often used to add basic constraints on every query. An example is the bundled SoftDelete template. Its listener adds extra constraints such as s.deleted_at IS NULL to a query, to make sure that deleted rows are never retrieved on a query. However, in the emitted SQL, Doctrine_Query does not use parentheses to group normal SQL conditions together. The pending join condition is simply added to the string without encapsulating existing expressions. This makes it possible to bypass the pending join conditions entirely by using the OR operator. Example For instance, the following query exhibits this problem:
This query emits the following SQL:
which returns also a deleted row. Expected behavior One would expect the pending join conditions always to hold, and to have precedence over regularly added SQL conditions. This could be accomplished in the most simple fashion by:
As the existing expressions are now encapsulated by parentheses, it is no longer possible to bypass the pending join conditions injected by the query listener. Full test case details: init.sql create database softdelete;
grant all privileges on softdelete.* to softdelete@localhost identified by 'uahwqeruwer';
use softdelete;
CREATE TABLE soft_delete_test (name VARCHAR(255),
deleted_at DATETIME DEFAULT NULL,
PRIMARY KEY(name)) ENGINE = INNODB;
insert into soft_delete_test values ('fine', null);
insert into soft_delete_test values ('faulty', now());
run.php <?php
require "./1.2.3/lib/Doctrine.php";
spl_autoload_register(array('Doctrine', 'autoload'));
require "SoftDeleteTest.php";
$conn = Doctrine_Manager::connection("mysql://softdelete:uahwqeruwer@localhost/softdelete");
$conn->setAttribute(Doctrine::ATTR_USE_DQL_CALLBACKS, true);
$query = Doctrine_Query::create()
->from("SoftDeleteTest")
->where("name=?", "faulty")
->orWhere("name=?", "faulty");
$found = $query->execute();
foreach ($found as $f) {
echo "ERROR! Found a deleted row: $f->name\n";
}
echo "Done.\n";
SoftDeleteTest.php (copied from Doctrine manual) <?php
class SoftDeleteTest extends Doctrine_Record
{
public function setTableDefinition()
{
$this->hasColumn('name', 'string', null, array(
'primary' => true
)
);
}
public function setUp()
{
$this->actAs('SoftDelete');
}
}
|
| Comments |
| Comment by Walter Hop [ 03/Dec/10 ] |
|
Fixing quote formatting |
| Comment by Walter Hop [ 03/Dec/10 ] |
|
Final formatting fixes. |
[DC-1035] ORA-01791 due to bad driver name in Doctrine_Adapter_Oracle Created: 01/Sep/11 Updated: 01/Sep/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Connection |
| Affects Version/s: | 1.2.4 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Jayson LE PAPE | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Windows 7 64 bits, PHP 5.2.11, Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi, Symfony 1.4.13 |
||
| Description |
|
When i execute this code:
$q = Doctrine_Query::create()
->from('AGENT ag')
->leftJoin('ag.CHANTIER_AGENT cag)
->orderBy('ag.nom')
->limit(10)
->execute();
$q2 = Doctrine_Query::create()
->from('AGENT ag')
->leftJoin('ag.CHANTIER_AGENT cag)
->orderBy('ag.nom')
->limit(10)
->execute();
Doctrine executes : SELECT a.pk AS a__pk, a.ts AS a__ts, a.ck_agent AS a__ck_agent, a.matricule AS a__matricule, a.nom AS a__nom, a.prenom AS a__prenom, a.agent_maitrise AS a__agent_maitrise, c.pk AS c__pk, c.ts AS c__ts, c.ck_chantier_agent AS c__ck_chantier_agent, c.ek_chantier AS c__ek_chantier, c.fk_chantier AS c__fk_chantier, c.ek_agent AS c__ek_agent, c.fk_agent AS c__fk_agent FROM AGENT a LEFT JOIN CHANTIER_AGENT c ON a.ck_agent = c.ek_agent WHERE a.ck_agent IN ( SELECT a2.ck_agent FROM ( SELECT DISTINCT a2.ck_agent, a2.nom FROM AGENT a2 LEFT JOIN CHANTIER_AGENT c2 ON a2.ck_agent = c2.ek_agent ORDER BY a2.nom ) a2 WHERE ROWNUM <= 10) ORDER BY a.nom SELECT a.pk AS a__pk, a.ts AS a__ts, a.ck_agent AS a__ck_agent, a.matricule AS a__matricule, a.nom AS a__nom, a.prenom AS a__prenom, a.agent_maitrise AS a__agent_maitrise, c.pk AS c__pk, c.ts AS c__ts, c.ck_chantier_agent AS c__ck_chantier_agent, c.ek_chantier AS c__ek_chantier, c.fk_chantier AS c__fk_chantier, c.ek_agent AS c__ek_agent, c.fk_agent AS c__fk_agent FROM AGENT a LEFT JOIN CHANTIER_AGENT c ON a.ck_agent = c.ek_agent WHERE a.ck_agent IN ( SELECT a2.ck_agent FROM ( SELECT DISTINCT a2.ck_agent FROM AGENT a2 LEFT JOIN CHANTIER_AGENT c2 ON a2.ck_agent = c2.ek_agent ORDER BY a2.nom ) a2 WHERE ROWNUM <= 10) ORDER BY a.nom This causes "Oracle DB Error ORA-01791 not a SELECTed expression" because the sql query don't have a2.nom in SELECT DISTINCT and it's indispensable for ORDER BY a2.nom protected $attributes = array(Doctrine_Core::ATTR_DRIVER_NAME => "oci8", Doctrine_Core::ATTR_ERRMODE => Doctrine_Core::ERRMODE_SILENT); The problem is in Query.php line 1417 : if ($driverName == 'pgsql' || $driverName == 'oracle' || $driverName == 'oci' || $driverName == 'mssql' || $driverName == 'odbc') {
The driver name declared in Doctrine_Adapter_Oracle not in this conditional. protected $attributes = array(Doctrine_Core::ATTR_DRIVER_NAME => "oracle", Doctrine_Core::ATTR_ERRMODE => Doctrine_Core::ERRMODE_SILENT); An other problem is probably located at line 1409 if (($driverName == 'oracle' || $driverName == 'oci') && $this->_isOrderedByJoinedColumn()) { and 1497 if (($driverName == 'oracle' || $driverName == 'oci') && $this->_isOrderedByJoinedColumn()) { if don't correct the declaration of $attributes in Doctrine_Adapter_Oracle. |
[DC-1034] ORA-00904 in Doctrine_Connection_Oracle Created: 01/Sep/11 Updated: 01/Sep/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Connection |
| Affects Version/s: | 1.2.4 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Jayson LE PAPE | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Windows 7 64 bits, PHP 5.2.11, Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi, Symfony 1.4.13 |
||
| Description |
|
When i execute this code:
$q = Doctrine_Query::create()
->from('AGENT ag')
->leftJoin('ag.CHANTIER_AGENT cag)
->orderBy('ag.nom')
->limit(10)
->offset(10)
->execute();
Doctrine executes : SELECT a.pk AS a__pk, a.ts AS a__ts, a.ck_agent AS a__ck_agent, a.matricule AS a__matricule, a.nom AS a__nom, a.prenom AS a__prenom, a.agent_maitrise AS a__agent_maitrise, c.pk AS c__pk, c.ts AS c__ts, c.ck_chantier_agent AS c__ck_chantier_agent, c.ek_chantier AS c__ek_chantier, c.fk_chantier AS c__fk_chantier, c.ek_agent AS c__ek_agent, c.fk_agent AS c__fk_agent FROM AGENT a LEFT JOIN CHANTIER_AGENT c ON a.ck_agent = c.ek_agent WHERE a.ck_agent IN (SELECT b.ck_agent FROM ( SELECT a.*, ROWNUM AS doctrine_rownum FROM ( SELECT DISTINCT a2.ck_agent, a2.nom FROM AGENT a2 LEFT JOIN CHANTIER_AGENT c2 ON a2.ck_agent = c2.ek_agent ORDER BY a2.nom ) a2 ) b WHERE doctrine_rownum BETWEEN 11 AND 20) ORDER BY a.nom The problem is in function _createLimitSubquery in Doctrine_Connection_Oracle :
$query= 'SELECT '.$this->quoteIdentifier('b').'.'.$column.' FROM ( '.
'SELECT '.$this->quoteIdentifier('a').'.*, ROWNUM AS doctrine_rownum FROM ( '
. $query . ' ) ' . $this->quoteIdentifier('a') . ' '.
' ) ' . $this->quoteIdentifier('b') . ' '.
'WHERE doctrine_rownum BETWEEN ' . $min . ' AND ' . $max;
Error occures, because table name is AGENT and Doctrine give the first letter of the table name for identifier.
$query = 'SELECT '.$this->quoteIdentifier('limb').'.'.$column.' FROM ( '.
'SELECT '.$this->quoteIdentifier('lima').'.*, ROWNUM AS doctrine_rownum FROM ( '
. $query . ' ) ' . $this->quoteIdentifier('lima') . ' '.
' ) ' . $this->quoteIdentifier('limb') . ' '.
'WHERE doctrine_rownum BETWEEN ' . $min . ' AND ' . $max;
|
[DC-651] [PATCH] Doctrine_Record::option('orderBy', ...) of join's right side being applied to refTable in m2m relationship Created: 26/Apr/10 Updated: 31/Aug/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Query, Relations |
| Affects Version/s: | 1.2.2, 1.2.3 |
| Fix Version/s: | 1.2.2, 1.2.3, 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | suhock | Assignee: | Guilherme Blanco |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | None | ||
| Environment: |
CentOS 5.4 |
||
| Attachments: |
|
| Description |
|
When using the Doctrine_Record::option('orderBy', ...) feature on a table definition, where that table is the target of a many-to-many join, the specified orderBy columns are applied to the relation table's alias. So for example, given the following definitions: class User extends Doctrine_Record { public function setTableDefinition() { $this->hasColumn('uid', 'integer', null, array('primary' => true)); $this->option('orderBy', 'uid'); } public function setUp() { $this->hasMany('Group as groups', array('refClass' => 'UserGroup', 'local' => 'user_uid', 'foreign' => 'group_id')); } } class Group extends Doctrine_Record { public function setTableDefinition() { $this->hasColumn('gid', 'integer', null, array('primary' => true)); } public function setUp() { $this->hasMany('User as users', array('refClass' => 'UserGroup', 'local' => 'group_gid', 'foreign' => 'user_id')); } } class UserGroup extends Doctrine_Record { public function setTableDefinition() { $this->hasColumn('user_uid', 'integer', null, array('primary' => true)); $this->hasColumn('group_gid', 'integer', null, array('primary' => true)); } public function setUp() { $this->hasOne('User as user', array('local' => 'user_uid', 'foreign' => 'uid')); $this->hasOne('Group as group', array('local' => 'group_gid', 'foreign' => 'gid')); } } the following queries: $query = Doctrine_Query::create()
->select('u.*')
->from('User u')
->leftJoin('u.groups g WITH g.gid=?', 1);
echo $query->getSqlQuery() . "\n";
$query = Doctrine_Query::create()
->select('g.*')
->from('Group g')
->leftJoin('g.users u WITH u.uid=?', 1);
echo $query->getSqlQuery() . "\n";
will output the following:
The orderBy option() call is applied to the User definition. The SQL for the first query is correct (where User is on the left side of the join). The SQL for the second query (where User is on the right-most side of the join), however, is obviously incorrect (UserGroup doesn't even have a uid column). Basically, User's orderBy option is being applied to both the User table and its respective reference table, UserGroup, when it is the target of a join. After digging through the source for a while, I believe I've come up with a patch for this issue (which should be checked by someone more knowledgeable of Doctrine's internals). Basically, in the Doctrine_Query::buildSqlQuery() function, a call is made to Doctrine_Relation::getOrderByStatement() with the reference table (UserGroup)'s alias (u2), which in turn makes a call to Doctrine_Table::getOrderByStatement() on the referenced table (User), filling in the ORDER BY clause with User columns using UserGroup's alias. My solution was to reorder the logic so that the test for a reference class is made before the initial call to getOrderByStatement() is made. It seems to work against my test case and the test cases in the repository. I'll post my patch momentarily. This bug was first mentioned in the comments in DC-313, but the original ticket comes across as more of a feature request for the hasMany() orderBy feature. |
| Comments |
| Comment by suhock [ 26/Apr/10 ] |
|
attached a test case for this bug |
| Comment by suhock [ 26/Apr/10 ] |
|
patch against /branches/1.2 HEAD (should also work apply to 1.2.2 tag) |
| Comment by Dan Ordille [ 30/Aug/10 ] |
|
I can confirm this as an issue. However I don't think the above patch adequately fixes the problem it seems like with it an order by is still added for the ref column however the relation alias is lost. My query with the patch became I made an another patch that prevents this extra order by clause from being added and have attached it. |
| Comment by suhock [ 21/Sep/10 ] |
|
I tried out the new patch (Query_orderby_relation.diff), but it provides a reversed diff (patching goes from a patched version to the original). After applying it manually, it fails the provided test case and several additional test cases from the repository. The original patch DOES pass the provided test case, when applied against 1.2.2, 1.2.3, or the 1.2 branch from the repository. It does not pass, however, Doctrine_Query_Orderby_TestCase. As the previous poster mentioned, it fails to resolve aliases in instances where the 'orderBy' option is specified in a relation definition. I deleted the original patch and am providing a revised patch (Ticket_DC651.patch) against branch 1.2 HEAD (also works with 1.2.3), which fixes this issue. It passes all working test cases, including Doctrine_Query_Orderby_TestCase and DC651TestCase. |
| Comment by José De Araujo [ 31/Aug/11 ] |
|
I had this issue recently on a application I'm working on as described the oderBy option was applied on the joined table on a column that even doesn't exist in it. I used the DC651 patch provided and it solved the issue, so far I haven't seen any side effect to it. |
[DC-1022] Doctrine migration does not set version when MySQL autocommit is false Created: 26/Jul/11 Updated: 26/Jul/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Migrations |
| Affects Version/s: | None |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Adam Fineman | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
RHEL 6.0, mysql 5.1.52 |
||
| Attachments: |
|
| Description |
|
With autocommit set to off in mysqld, Doctrine_Migration::setCurrentVersion() does not have any effect. This is because the method uses raw PDO calls, which are discarded without either autocommit or an explicit COMMIT;. We patched Doctrine as in the attachment. It works for us, but may not be the best general solution. The patch only fixes this one issue. There are likely many areas in Doctrine that rely upon autocommit behavior in MySQL. We will continue to look for them, and supply patches as we find them. However, as we are only concerned about MySQL, our solutions will probably not apply to other PDO drivers. |
[DC-1021] i am executing doctrine type query i am geting error please gave me reply Created: 24/Jul/11 Updated: 24/Jul/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | None |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | cherukuri | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
windows ,wamp,php |
||
| Description |
|
$query = new Doctrine_Query(); |
[DC-1007] Cannot update a field to NULL with MSSQL connection Created: 25/May/11 Updated: 25/May/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Connection |
| Affects Version/s: | None |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Critical |
| Reporter: | guitio2002 | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Windows 7 32 bits with Apache 2.2.x, PHP 5.2.17, Sql Server 2008, Symfony 1.4.11 and Doctrine 1.2.4 |
||
| Description |
|
When trying to update a field to NULL in a MSSQL database, Doctrine generates the following request: UPDATE table SET fieldThatMustBeNull = , anotherField = 'blabla'; therefore generating a syntax error. A fix would be to override the update method in the Doctrine_Connection_Mssql and add the following behavior: Doctrine_Connection_Mssql public function update(Doctrine_Table $table, array $fields, array $identifier) { if (empty($fields)) { return false; } $set = array(); foreach ($fields as $fieldName => $value) { if ($value instanceof Doctrine_Expression) { $set[] = $this->quoteIdentifier($table->getColumnName($fieldName)) . ' = ' . $value->getSql(); unset($fields[$fieldName]); } else if (is_null($value)) { $set[] = $this->quoteIdentifier($table->getColumnName($fieldName)) . ' = NULL'; unset($fields[$fieldName]); } else { $set[] = $this->quoteIdentifier($table->getColumnName($fieldName)) . ' = ?'; } } $params = array_merge(array_values($fields), array_values($identifier)); $sql = 'UPDATE ' . $this->quoteIdentifier($table->getTableName()) . ' SET ' . implode(', ', $set) . ' WHERE ' . implode(' = ? AND ', $this->quoteMultipleIdentifier($table->getIdentifierColumnNames())) . ' = ?'; return $this->exec($sql, $params); } |
[DC-1004] ATTR_TBLNAME_FORMAT not used when creating models from database Created: 08/May/11 Updated: 08/May/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Import/Export |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.3, 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Robin Parker | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
| Description |
|
if you set prefix to "xyz_%s" and have the model "BackgroundColor" it will become the table => "xyz_background_color" The fix (diff):
|
| Comments |
| Comment by Robin Parker [ 08/May/11 ] |
|
The diff output as .diff |
[DC-1003] _processWhereIn does not allow the use of named query parameters Created: 05/May/11 Updated: 06/May/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Query |
| Affects Version/s: | None |
| Fix Version/s: | 1.2.4 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | alex pilon | Assignee: | Guilherme Blanco |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
karmic, php 5.2.10, apache2 |
||
| Attachments: |
|
| Description |
|
When writing a query such as
you are unable to then
Doctrine complains that you may not mix positional and named query parameters. The attached patch fixes this by checking if the key of the passed in parameter is non numeric and if so setting the "value" of the parameter place holder to the value of the key. |
| Comments |
| Comment by alex pilon [ 05/May/11 ] |
|
I discovered an issue with the above patch. I am working on a better version. |
| Comment by alex pilon [ 06/May/11 ] |
|
Here is a second version.. it is a little bit sloppy. Is there a resource I can find on here that will help me to improve code quality/unit test this? |
[DC-856] Doctrine_Core::getPath() not working when inside phar, due to a bug in php Created: 03/Sep/10 Updated: 04/Jan/11 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | None |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Miha Vrhovnik | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
It seems that there is a bug in php, and realpath doesn't work when path is inside of phar archive. can be easily changed to |
| Comments |
| Comment by Pierre-Gildas MILLON [ 04/Jan/11 ] |
[DC-951] Error in generating the field size and error in the generation of the date fields for postgres Created: 24/Dec/10 Updated: 24/Dec/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | None |
| Affects Version/s: | 1.2.2 |
| Fix Version/s: | 1.2.4 |
| Type: | New Feature | Priority: | Major |
| Reporter: | fernando guerrero | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
apacha2, linux, Symfony 1.4 |
||
| Description |
|
collaboration of vtamara@pasosdejesus.org and jeronimo0000@gmail.com While we developed a tool with symfony 1.4 and postgresql database we found errors in the generated schema.yml which I describe below 1 - Error in generating of field size of varchars We found the following solution — Doctrine/Import/Pgsql.php.orig 2010-12-23 17:48:00.160271000 -0500
$decl = $this->conn->dataDict->getPortableDeclaration($val); |
[DC-701] Aggregates functions do not return proper values when using many relationships and limits Created: 24/May/10 Updated: 01/Nov/10 |
|
| Status: | Reopened |
| Project: | Doctrine 1 |
| Component/s: | None |
| Affects Version/s: | 1.2.2 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | will ferrer | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
XP Xamp |
||
| Attachments: |
|
| Description |
|
Hi All I have encountered a problem that seems very core to the way that doctrine works – if you apply an aggregate function to a column in a table and then join to another table via a many relationship while also using a limit, like so: $q = Doctrine_Query::create();
$q->from('Customer Customer');
$q->addSelect('COUNT(Customer.id) as COUNT_customer_id');
$q->addSelect('Customer_Order.id as order_id');
$q->leftJoin('Customer.Order Customer_Order'); // Many relationship here
$q->limit(20);
It produces this correct DQL: SELECT COUNT(Customer.id) as COUNT_customer_id, Customer_Order.id as order_id FROM Customer Customer LEFT JOIN Customer.Order Customer_Order LIMIT 20 However the SQL it produces will not return an accurate count – the count is restricted by the limit: SELECT COUNT(p.id) AS p__0, p2.id AS p2__1
FROM product_customers p
LEFT JOIN product_orders p2 ON p.id = p2.customer_id
WHERE p.id IN ('1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20')
This produces a count of 21 instead of what it should be (1000). The reason for this is because Doctrine's internal functionality does an intermediary query where it gets gets the ids needed from the customer table in order to use them as the IN portion of the constraints on the final query – like so: SELECT DISTINCT p3.id FROM product_customers p3 LIMIT 20 It may seem strange that I am applying a limit to a query which will aggregate to 1 to row . In the actual queries that alerted me to this problem I am using a group by. The reason I am not reporting this bug with a group by in my example however is that you can not use a group by with a many relationship and a limit in doctrine 1.2.2 as it works currently (see bug: Here is my sample schema in case its helpful. detect_relations: false package: Example options: type: INNODB charset: utf8 Order: tableName: orders columns: order_id: type: integer(4) primary: true notnull: true customer_id: type: integer(4) order_date: timestamp relations: Customer: type: one local: customer_id foreign: customer_id options: type: InnoDB Customer: tableName: customers columns: customer_id: type: integer(4) primary: true notnull: true autoincrement: true firstname: type: string(45) lastname: type: string(45) streetaddress: type: string(45) city: type: string(45) state: type: string(45) postalcode: type: string(45) relations: Order: type: many local: customer_id foreign: customer_id options: type: InnoDB Thanks much. Will Ferrer edit: split SQL code to make the discussion readable without huge horizontal scrolling... |
| Comments |
| Comment by Jonathan H. Wage [ 08/Jun/10 ] |
|
Is this still a problem? I am not sure if this can be patched easily. The limit subquery algorithm is flawed deeply but also a core part of the current way Doctrine 1 works. |
| Comment by will ferrer [ 08/Jun/10 ] |
|
Hi Jon This bug is still an issue for me but I think it may be VERY hard to patch since it seems very core to the way Doctrine 1 works. The project I am working on at the moment is a visual query builder that is highly reliant on Doctrine. In order to prevent users from making queries that would trigger this bug I am currently giving an alert when ever a query that would trigger this bug is created. It would be great if this were patchable but if not I should be able to get by. Does Doctrine 2 fix this problem? Thanks for the help. Will Ferrer |
| Comment by Jonathan H. Wage [ 08/Jun/10 ] |
|
In Doctrine 2 the limit subquery algorithm does not exist. It is now up to the developer to write the query to handle the scenario instead of Doctrine "trying" to automate it for you. Since the situation where it is needed it is so rare, and each case can be slightly different it is better to let the developer handle it in those cases. |
| Comment by will ferrer [ 08/Jun/10 ] |
|
Hi Jon Does that mean that Doctrine 2 can no longer intelligently handle limits with many relationships, and doesn't have the ability to hydrate a return with sub arrays in it for many relationships? Thanks again for your help. Will Ferrer |
| Comment by Jonathan H. Wage [ 09/Jun/10 ] |
|
That is correct. We do not automatically try and limit the relationships with a "limit subquery" as it causes more problems then it helps. |
| Comment by will ferrer [ 10/Jun/10 ] |
|
Hi Jon I was thinking about what you said here – that the "limit subquery" causes more harm than good. It occur to me that I really do like being able to use this method (it comes in very handy very often) but some times it would really help to be able to turn it off (the bug in this thread is a good example such a time). So I figured why not just make an option to turn it off and have the best of both worlds? I looked at the code and found it was really very easy to put in a property which can be set on the query object to enable or disable the use of the limit subquery. I made the change in my code base and found it very useful for several situations I was dealing with in my own project. The one thing I couldn't do is make a test case for this new feature – I couldn't find an existing test case that was actually triggering the limit subquery as I understood it to work (I couldn't find a test case that would put an WHERE IN constraint with all the ids gathered in the limit subquery. I tried some test cases that I THOUGHT would activate this feature but it didn't seem that they did). After adding this feature to my code base I also wanted a new hydrator – one that worked like scalar but would put in array key names that were the same as the ones you would see in HYDRATE_ARRAY. I noticed that HYDRATE_SCALAR already had the ability to do this but it required that a value of false be passed into the $aliasPrefix argument of the _gatherRowData function. I made a custom hydrator I call HYDRATE_ARRAY_SHALLOW that passes in this false value. I then realized this might be handy to add to doctrine so I integrated it into my code base and made a few test cases for it. There are 2 patches I am now attaching this to thread: disableLimitSubquery_2010-06-10_Doctrine_1.2_SVN.patch – this patch adds the disableLimitSubquery property to query objects so that users can turn off the use of the subquery for those times when they don't want to use that behavior (fixing the bug in this thread and probably others) and disableLimitSubquery_and_HYDRATE_ARRAY_SHALLOW_2010-06-10_Doctrine_1.2_SVN.patch – this is the same as the first patch but also contains the HYDRATE_ARRAY_SHALLOW hydration type I mentioned above (which tends to go well with disableLimitSubquery turned on). I put these in 2 patches incase you liked 1 feature but disliked the other. If you like either of this features I would be very happy to see them added to doctrine. Also if you have any advice on how to improve these features (or info on how to make a good test case for disableLimitSubquery) please let me know. Hope you are well. Will Ferrer |
| Comment by will ferrer [ 10/Jun/10 ] |
|
Reopened because I added a patch that I think in essence fixes the issues. |
| Comment by Jonathan H. Wage [ 01/Sep/10 ] |
|
Thanks for the issue and patches. Fixed here http://github.com/doctrine/doctrine1/commit/2ad78e62e360133efc04bf6897bf679c7f3d833b |
| Comment by will ferrer [ 01/Sep/10 ] |
|
individual patch for this issue with out other features included |
| Comment by will ferrer [ 01/Nov/10 ] |
|
adding test cases for these features |
| Comment by will ferrer [ 01/Nov/10 ] |
|
reopened because I posted some test cases to add to doctrine along with the patchs previously posted |
[DC-898] (PATCH) Migration fails when addColumn with type 'boolean' used with default value, resulting in incorrect 'ALTER TABLE' query in MySQL Created: 22/Oct/10 Updated: 22/Oct/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Import/Export |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Jakub Argasiński | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Mac OS X 10.6 Snow Leopard / Zend Server CE 5.0.3 (irrelevant) |
||
| Attachments: |
|
| Description |
|
I use MySQL. In my up() method in migration class, I have: $this->addColumn($table, 'is_master', 'boolean', null, array('notnull' => true, 'default' => false)); Running 'migrate' results in a following exception: However, I would expect ALTER query to look like this: ALTER TABLE books_authors ADD is_master TINYINT(1) DEFAULT 0 NOT NULL I guess there's a problem with getDefaultFieldDeclaration() in Doctrine_Export_Mysql, it lacks convertBooleans() call being present at Doctrine_Export. |
[DC-831] Importing fixtures fails when GoogleI18n used with "Couldn't create collection index. Record field 'lang' was null." Created: 17/Aug/10 Updated: 13/Oct/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Data Fixtures, I18n, Import/Export |
| Affects Version/s: | 1.2.2, 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Jakub Argasiński | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Mac OS X 10.6.4, Zend Server CE 5.0.2 (irrelevant, I guess) |
||
| Attachments: |
|
| Description |
|
There's a problem with Doctrine_Data_Import. When trying to load a fixture record with translations, and GoogleI18n (or similar) instead of I18n is used (via actAs()), the following crash happens: #0 /Users/argasek/Sites/fwm/library/doctrine/Doctrine/Access.php(131): Doctrine_Collection->add(Object(Fwm_Shop_Catalog_CategoryTranslation)) I have narrowed down the problem to the line 135 of Doctrine/Data/Import.php, ie. if ($table->hasRelation($key) && is_array($value) && ! $table->hasTemplate('Doctrine_Template_I18n')) { In case of GoogleI18n, $table->hasTemplate('Doctrine_Template_I18n') returns false. I have no idea how to patch this in a sane way. Adding another condition (&& ! $table->hasTemplate('Doctrine_Template_GoogleI18n') serves well as a workaround, but such condition would be required for any class similar to Doctrine_Template_GoogleI18n. I guess the condition should check if it's a Doctrine_Template_I18n template or any template iherited from this class?... |
| Comments |
| Comment by Jakub Argasiński [ 17/Aug/10 ] |
|
I have provided a quick workaround patch for this problem, with an approach described in my report, ie. checking whether table has a template being an instance of or a child of Doctrine_Template_I18n. |
[DC-883] Help for Test CLI does not list available test groups Created: 10/Oct/10 Updated: 10/Oct/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | None |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Andrew Coulton | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The CLI Test Runner is supposed to print a list of available test groups when used with the --help parameter, but this fails as the Doctrine_Test::run() method erroneously expects php sort() to return an array rather than a boolean. Fixed by http://github.com/acoulton/doctrine1/tree/DC-883 |
[DC-881] Doctrine_Manager::parsePdoDsn() doesn't work properly [+patch] Created: 08/Oct/10 Updated: 08/Oct/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Connection |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Enrico Stahn | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Doctrine_Manager::parsePdoDsn('dblib:host=127.0.0.1:1433;dbname=foo') does not return proper results. patch and test case @ github |
[DC-879] MSSQL - missing function date_part() in Expression/Mssql.php [+patch] Created: 05/Oct/10 Updated: 05/Oct/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Connection |
| Affects Version/s: | 1.2.2, 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Enrico Stahn | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Missing function date_part() in Expression/Mssql.php. I don't know why the set of expressions is different for each driver. This makes it hard to develop database independent. |
[DC-756] Cannot use named parameters in a 'limit(':max') clause Created: 21/Jun/10 Updated: 07/Sep/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Dennis Gearon | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
ubuntu, apache, symfony version 1.4.4 |
||
| Attachments: |
|
| Description |
|
$modulus=5; This works This does not, it gets the whole table |
| Comments |
| Comment by Dennis Gearon [ 24/Jun/10 ] |
|
I noticed an error in the code, which does not solve the problem, only confuse whomever works on it $maxDaysDetailsToProcess=3; as the fourth line in the code. |
| Comment by Juan Antonio Galán [ 07/Sep/10 ] |
|
I think I found a solution but it's making some tests fail. Let me explain you what I did: First I removed any casting to int of the limit value, in order to keep the named parameter in the LIMIT part of the query. Actually this named parameters were converted to 0 due to those int castings. Then I realized that the params are bound as strings so the resulting query looks like ... LIMIT "2" or whatever you put in the limit value, and mysql throws and error. Then I tryed to modify the function that binds the paramters to bind them as integers when they're not strings. Everything seems to work fine and you could put named parameters in the limit clause, but some tests are failing. If you look at the tests that are failing you'll see that they're failing because of a wrong phone number, the test it's expecting a number large number like 6155139185 but the result array has a number like 1860171889. I'm wondering if there's something wrong when binding numbers bigger than mysql INT as integers. I attach a diff file with the changes I did, hope it helps |
[DC-843] MSSQL - Equal-to Operator doesn't work with columns of type text in where condition [+patch] Created: 26/Aug/10 Updated: 02/Sep/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Connection |
| Affects Version/s: | 1.2.2, 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Enrico Stahn | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Example: Doctrine::getTable('Ticket_DCXXX2_Model')->findByUsernameAndFoo('foo', 'bar');
foo is of type "text". Doctrine generates "where .... foo = 'bar'", but this will throw an mssql exception because you cant use the equal to operator in mssql for text and varchar types. Doctrine should consider this database related behavoir, shouldn't it? |
| Comments |
| Comment by Enrico Stahn [ 26/Aug/10 ] |
|
TestCase added http://github.com/estahn/doctrine1/compare/master...DC-843 |
| Comment by Enrico Stahn [ 27/Aug/10 ] |
|
Patch added to github (see above) commit msg: DC-843 fix (TestCase need fix for DC-841 to run successfully) |
| Comment by Enrico Stahn [ 02/Sep/10 ] |
|
I made a mistake with github, the updated branch can be found at |
[DC-852] CLONE -Fix returned type value : SQL integers to PHP integers when getting a value from the database. Created: 01/Sep/10 Updated: 02/Sep/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Attributes, Data Fixtures, Native SQL, Query, Record |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Enrico Stahn | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Hi Jon, I have a request for you to improve Doctrine. When declaring a column as an integer, it seems that Doctrine returns a string when getting the value of that column. For example, if I have a "status" column, which can take 0, 1 or 2 as its value, Doctrine will return these values as string, which is not really logical and returning the good PHP type is the goal of an ORM. I'm fond of the triple equal symbol to test a value and I did not understand why this did not work at start : // in my myModel class public function isValidated() { return self::STATUS_VALIDATED === $this->getStatus(); }} That's why getStatus() gives me a string instead of an integer, whereas the column is declared as an integer in my schema. I'm forced to cast myself the returned value of getStatus() in my model. |
| Comments |
| Comment by Enrico Stahn [ 01/Sep/10 ] |
|
Proposal for a solution: http://github.com/estahn/doctrine1/compare/master...DC-852 |
| Comment by Jonathan H. Wage [ 01/Sep/10 ] |
|
So if you enable this attribute you live with the fact that casting a string to an integer that is longer than php max integer will give weird results? |
| Comment by Enrico Stahn [ 02/Sep/10 ] |
|
i'm far from happy with this solution. if an integer that is greater than php max int gets casted it will be casted into a value of type double. if you enable that attribute only values that could successfully casted into an integer will be casted otherwise an exception will be thrown. |
[DC-828] MSSQL - ORDER BY on text columns throws mssql error 306 [+patch] Created: 16/Aug/10 Updated: 02/Sep/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Query |
| Affects Version/s: | 1.2.2 |
| Fix Version/s: | 1.2.4 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Enrico Stahn | Assignee: | Guilherme Blanco |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
Throws: Server: Msg 306, Level 16, State 2, Line 1
The text, ntext, and image data types cannot be compared or sorted, except when using IS NULL or LIKE operator.
Solution:
References:
Patch will be supplied soon ... |
| Comments |
| Comment by Enrico Stahn [ 20/Aug/10 ] |
|
http://github.com/estahn/doctrine1/compare/DC-828 I guess we need more TestCases for the SubQuery stuff. |
| Comment by Enrico Stahn [ 02/Sep/10 ] |
|
I made a mistake with github, the updated branch can be found at |
[DC-840] MSSQL - strange behavior with multiple addWhere conditions and ">" [+patch] Created: 25/Aug/10 Updated: 27/Aug/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Connection |
| Affects Version/s: | 1.2.2, 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Trivial |
| Reporter: | Enrico Stahn | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
In the first example below the second parameter wasn't replaced by the given value. I tracked it down and i suppose it's because of the ">" sign. It's the same for "<". Equal-Operator (=) works fine. $q = Doctrine_Query::create()
->select('password, modified_at')
->from('Ticket_DCXXX_Model')
->andWhere('password = ?', 'abc')
->andWhere('modified_at > ?', '2010-01-01')
SELECT [t].[id] AS [t__id], [t].[password] AS [t__password], [t].[modified_at] AS [t__modified_at] FROM [ticket__d_c_x_x_x__model] [t] WHERE ([t].[password] = 'abc' AND [t].[modified_at] > ?) $q = Doctrine_Query::create()
->select('password, modified_at')
->from('Ticket_DCXXX_Model')
->andWhere('modified_at > ?', '2010-01-01')
->andWhere('password = ?', 'abc')
SELECT [t].[id] AS [t__id], [t].[password] AS [t__password], [t].[modified_at] AS [t__modified_at] FROM [ticket__d_c_x_x_x__model] [t] WHERE ([t].[modified_at] > '2010-01-01' AND [t].[password] = 'abc') |
| Comments |
| Comment by Enrico Stahn [ 25/Aug/10 ] |
| Comment by Enrico Stahn [ 27/Aug/10 ] |
|
see DC-841 |
[DC-825] Versionable does not work with column alias on primary keys [+patch] Created: 13/Aug/10 Updated: 25/Aug/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Behaviors |
| Affects Version/s: | 1.2.2 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Enrico Stahn | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
| Description |
|
Using the Versionable behavior on a model which has a column with an alias and which is also primary causes the generation of a wrong version of the versionable table. Example: ModelFoo: model_id as id username password Generates tables: It should be: |
| Comments |
| Comment by Enrico Stahn [ 13/Aug/10 ] |
|
TestCase and Fix |
| Comment by Enrico Stahn [ 18/Aug/10 ] |
|
The supplied patches are not up-to-date. Pls use http://github.com/estahn/doctrine1/tree/DC-825 |
[DC-791] [PostgreSQL] In case model is build from existing database sequence name is invalid and doctrine throw exception Created: 16/Jul/10 Updated: 25/Aug/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Schema Files |
| Affects Version/s: | 1.2.2 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Przemysław Ciąćka | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
symfony 1.4.5, postgresql 8.4, debian lenny, nginx |
||
| Attachments: |
|
| Description |
|
Firstly I created database directly in postgresql. When I try to insert new record to database I received following error: sequence "Category_id_seq" does not exist In schema file sequence name is defined like this: sequence: '"Address_id_seq"' In Category model file is same like above, apostrophes and quotes. When I remove quotes from sequence in model files everything is ok and there're no problems with insert new row to database. |
| Comments |
| Comment by Enrico Stahn [ 13/Aug/10 ] |
|
There are 2 solutions to your problem. The first is to change the sequence name in the schema, the second is to change the doctrine configuration. The default behavior of doctrine is to add a "_seq" to each sequence name. If you remove this part from you sequence name then it sould work as expected. The second option is to change the behavior of doctrine with the following configuration parameter: Doctrine_Manager::getInstance()->setAttribute(Doctrine_Core::ATTR_SEQNAME_FORMAT, '%s'); default: Doctrine_Manager::getInstance()->setAttribute(Doctrine_Core::ATTR_SEQNAME_FORMAT, '%s_seq'); |
| Comment by Przemysław Ciąćka [ 25/Aug/10 ] |
|
Problem are quotes in sequence name. Temporarly I fixed it by add str_replace() into importer from PostgreSQL - now in schema sequence names are without quotes. |
[DC-769] Variable type different for return value from Doctrine_Record->toArray() depending on whether the object is from a select, or a save. Created: 27/Jun/10 Updated: 24/Aug/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | None |
| Affects Version/s: | 1.2.1 |
| Fix Version/s: | 1.2.1, 1.2.2, 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Dennis Gearon | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Ubuntu9.10, PHP 5.2.6, Symfony 1.4.1, Postgres8.4 |
||
| Description |
|
With a object that is created via a save(), and the record's primary key is a INT fed by a SEQUENCE, the type of the variable is an INT. With an object that is hydrated from the database via a SELECT, the record's primary key INT will come back in 'toArray()' as a STRING. That means that checking for type has to know what context it came from, user, INSERT, or SELECT. Not fun. This also screws up converting arrays to JSON, 'cause the STRINGS get quotation marks and the INTS do not. As a general rule, everything FROM the database seems to be strings. Yes, I know, everything 'on the wire' or 'through a socket' comes out as text. And it's a lot faster to leave it that way. But having the type be different depending on the database operation? Not sure I like that. |
| Comments |
| Comment by Jonathan H. Wage [ 24/Aug/10 ] |
|
Can you provide a test case so that we can see if we can come up with a patch? |
[DC-758] CascadeDelete not work properly on Versionable and on the AuditLog Created: 21/Jun/10 Updated: 24/Aug/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Behaviors |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Jaime Suez | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Mac OS X Snow Leopard, LAMP and Macports |
||
| Description |
Schema:
Personal:
actAs:
Versionable:
deleteVersions: false
cascadeDelete: false
When you use this configuration and try to delete one of the record linked with the versionned one, an exception about foreign key is raised because the id of the versioned record has a foreign key to the id of the record. It's necessary to could work with cascadeDelete: false... because like that it's needed to use softDelete and the deleted record's will be stored on the version table, but with the advantage that you don't have the performance problem of soft delete behaviour. Thanks! |
[DC-741] Sort of Migration Class Problem With More Than 9 Classes Created: 16/Jun/10 Updated: 24/Aug/10 |
|
| Status: | Open |
| Project: | Doctrine 1 |
| Component/s: | Cli |
| Affects Version/s: | 1.2.2 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Dolly Aswin Harahap | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Ubuntu 10.04, PHP 5.3.2, Doctrine 1.2.2 |
||
| Attachments: |
|
| Description |
|
I have problem when do a migration with more than 9 classes. (Version1, Version2, Version3, ..., Version10) php doctrine-cli.php migrate 10 When migration class lower than 10, migration well done. I have do a simple research, and found the problem is on the sort of the class name. So, I change the sort method to Natural Sort, to fix this issue. |
| Comments |
| Comment by Dolly Aswin Harahap [ 16/Jun/10 ] |
|
Here I attach patch to fix this issue. Please check it. |
| Comment by Jonathan H. Wage [ 24/Aug/10 ] |
|
I am not able to produce the error, things are always in the correct order. I added a test here: http://trac.doctrine-project.org/changeset/7683 Can you help me with how to reproduce the error? |