[DC-1049] error with Timestamp data Validation Created: 26/Feb/12  Updated: 17/Apr/14

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

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

Linux


Attachments: File Timestamp.php    

 Description   

The default value for timestamp is "0000-00-00 00:00:00", so
$e = explode('T', trim($value))
should be changed to
$e = explode(' ', trim($value))

public function validate($value)
{
if (is_null($value))

{ return true; }

$e = explode('T', trim($value));
$date = isset($e[0]) ? $e[0]:null;
$time = isset($e[1]) ? $e[1]:null;

$dateValidator = Doctrine_Validator::getValidator('date');
$timeValidator = Doctrine_Validator::getValidator('time');

if ( ! $dateValidator->validate($date))

{ return false; }

if ( ! $timeValidator->validate($time)) { return false; }

return true;
}






[DC-835] Inconsistent record validation on a notnull foreign key when the local relation is set Created: 19/Aug/10  Updated: 24/Aug/10

Status: Open
Project: Doctrine 1
Component/s: Record, Relations, Validators
Affects Version/s: 1.2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Adam Huttler Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File dc-835-patch.txt     File ForeignKeysTestCase.php    

 Description   

Doctrine_Validator_ForeignKeys_TestCase#testForeignKeyIsValidIfLocalRelationIsSet()

This test passes fine as is. But it fails if I make the following change:

public function testForeignKeyIsValidIfLocalRelationIsSet()
{
    //$person = new TestPerson();
    $address = new TestAddress();
        
    //$address->Person = $person;    
    $address->Person->first_name = "John";
        
    $table = $address->getTable();
    $errors = $table->validateField('person_id', $address->person_id, $address);
        
    $this->assertEqual(0, $errors->count());
}

The only difference is that instead of explicitly assigning $address->Person, I'm letting it happen automatically when assigning the first name. What is it about the property chaining when creating the related record that screws up doctrine's internal reference tracking?



 Comments   
Comment by Adam Huttler [ 19/Aug/10 ]

This is an existing test case for which I've added two tests. The first one fails, while the second passes. The first one captures the issue I'm experiencing.

Comment by Adam Huttler [ 24/Aug/10 ]

This patch augments the test file with the new test and also makes a change to Doctrine_Related_LocalKey that causes the test to pass.

Unfortunately, it causes another test to fail: 1072.

I don't fully understand test 1072, but it appears to be testing closely related behavior (i.e. relation chaining).

What do you think?





[DC-676] Validation exception thrown only if internal nesting level == 1 Created: 10/May/10  Updated: 08/Jun/10

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

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

PHP 5.3.1, Mac OS X 10.6


Attachments: File DC676TestCase.php    

 Description   

I wonder why Validation exception is thrown only if internal nesting level of transaction is 1 and the manual nesting level is not considered.

Line 262 - lib/Doctrine/Transaction.php:

if ($this->_internalNestingLevel == 1) {
    $tmp = $this->invalid;
    $this->invalid = array();
    throw new Doctrine_Validator_Exception($tmp);
}

I have a large database with a lot of tables and relationships. At some case the validation exception is not thrown if the validation fails.

If I add $this->_nestingLevel into this condition:

if ($this->_internalNestingLevel == 1 || $this->_nestingLevel == 1) {
    $tmp = $this->invalid;
    $this->invalid = array();
    throw new Doctrine_Validator_Exception($tmp);
}

Then the validation exception is thrown as excepted.

I don't know why you ignore here the nesting level.

It would be great if you could explain me more about these lines.

I ran the unit test with this modification and got the same result.



 Comments   
Comment by Fabian Spillner [ 10/May/10 ]

Additional information: On doctrine 1.1.x the exception is thrown without this modification.

Comment by Fabian Spillner [ 11/May/10 ]

It seems, the problem is the counter of internal nesting level. I output these member variables:

Doctrine 1.1.2

Doctrine_Transaction::commit invalid is not empty - internal nesting level: 1 nesting level: 2

ok 1 - Article cannot be created if empty: Doctrine_Validator_Exception: Validation failed in class Article

  1 field had validation error:

    * 1 validator failed on slug_title (notnull)

Doctrine 1.2.2

Doctrine_Transaction::commit invalid is not empty - internal nesting level: 0 nesting level: 1

not ok 1 - Empty Artcile could be created!
Comment by Fabian Spillner [ 11/May/10 ]

Yeah! I found the reason:

I attached a template (listener) into my model which validates the body and this method call:

// ...
if ($obj->getAuthor()->getAge())  # this creates new empty Author object
{
  // ...
}
// ...

On Doctrine 1.1, the method saveGraph() of class UnitOfWork executes first saveRelatedLocalKeys and then the hooks methods (preSave, etc.) and my code works!

On Doctrine 1.2, the method saveGraph() call *first* the hooks method and then the saveRelatedLocalKeys which save the empty author object and then destroy the internal nesting level
and the validation exception is not thrown.

Workaround for my listener:

// ...
if ($obj->relatedExists("Author") && $obj->getAuthor()->getAge())  # relatedExists() needed to avoid create empty Author object
{
  // ...
}
// ...

What do you think: It's a bug or a feature?

Comment by Fabian Spillner [ 11/May/10 ]

A test case attached to reproduce the bug.

The test passes if you remove the custom save() method of Ticket_DC676_Author class.

The problem: default "foobar" modifies the Author and is modified. Doctrine tries to save it,
but because there is more than two transactions, the validation exception is not thrown for Article object.

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

Something that really helps with determining what we should do is to find the exact changeset that causes the behavior. If we can look at what code was changed, we can then understand better what to do.

Comment by Fabian Spillner [ 20/May/10 ]

This changeset affects the problem:
http://trac.doctrine-project.org/changeset/6126/branches/1.2/lib/Doctrine/Connection/UnitOfWork.php

But I really don't like this logic how the validation exception is handled. I would seperate these things:

The method validate() should throw exception, and the method commit() should commit only if model is valid and nothing more.

1. go recursive into the model and call the validate() method

2. if not valid, exception is thrown

3. elseif ok, commit is called

PS. Sorry for late answer: I had a lot of work ...

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

Do you see something with that commit that could be changed that fixes your issue?

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

Whoops. This change is causing some problems. It causes lots of tests to fail in our test suite. Reverting for now. Can you try your change against our test suite and see if you can determine anything? Thanks, Jon





[DC-629] Doctrine Integer Validator should use intval() rather than round(floatval()) Created: 14/Apr/10  Updated: 08/Jun/10

Status: Open
Project: Doctrine 1
Component/s: Validators
Affects Version/s: 1.2.0-ALPHA1, 1.2.0-ALPHA2, 1.2.0-ALPHA3, 1.2.0-BETA1, 1.2.0-BETA2, 1.2.0-BETA3, 1.2.0-RC1, 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

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

Ubuntu 9.10 x64, php 5.2.10



 Description   
echo PHP_INT_MAX;
echo "\n";
echo strval(round(floatval(PHP_INT_MAX)));

on 64 bit machine, default php install, you get:

9223372036854775807
9.22337203685E+18

float precision is set to 12 by default. setting it higher offers no benefit, with it set to 20+, it still doesn't match up (and is actually not reliably past a certain length, i'd have to dig again to find a reference though), but as you can see, no go:

9223372036854775807
9223372036854775808

as a result, very large #'s do NOT validate as doctrine integers, even though they are.

fix, use intval() instead. as far as I can tell, and as far as our 400+ unit tests in our application show, PHP_INT_MAX is fully supported everywhere else except for in Validator.php@170:

170c170
<                  return (string) $var == strval(round(floatval($var)));
---
>                  return (string) $var == strval(intval($var));


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

This breaks a test:


Doctrine_Ticket_1783_TestCase...................................................failed


Doctrine_Ticket_1783_TestCase : method testValidateLargeIntegers failed on line 17 




[DC-624] Validator_Readonly fails for new objects Created: 09/Apr/10  Updated: 09/Apr/10

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

Type: Bug Priority: Major
Reporter: Tomasz Wysocki Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File Readonly.php    

 Description   

If Readonly validator is on for some field, it fails when you trying to create new object (ie. by loading fixtures).

Fix proposition is in attachment.






[DC-965] Doctrine is passing timestamps to Doctrine_Validator_Unsigned Created: 11/Feb/11  Updated: 11/Feb/11

Status: Open
Project: Doctrine 1
Component/s: Validators
Affects Version/s: 1.2.2, 1.2.3
Fix Version/s: None

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

Debian Lenny (5.0.8) with MySQL (5.0.51a-24+lenny5O). Doctrine hosted within CodeIgniter v1.7.2



 Description   

Since April last year I've been unable to use Doctrine Timestampable functionality because I get errors like this:

Uncaught exception 'Doctrine_Validator_Exception' with message 'Validation failed in class XXX 1 field had validation error: * 1 validator failed on created_at (unsigned) ' in ...

I've tried lots of different configurations for the timestampable functionality (see my Stack Overflow question for details) to no avail.

I've done some further investigation and the reason for the problem is that the timestamps are being sent to Doctrine_Validator_Unsigned for validation; they are then failing the following regexp test:

        if (preg_match('/[^0-9\-\.]/', $value)) {
            return false;
        }

I'm not smart enough to figure out why Doctrine is calling an unsigned validation test for these timestamps, so for now I've fixed the problem by hacking the following into Doctrine_Validator_Unsigned:

        if (preg_match('/\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/', $value)) {
            return true;
        }

Very ugly I know, but when I add this in the rest of the timestamping functionality works perfectly. Would love to get to the bottom of this bug - is particularly strange because nobody else seems to be experiencing it.



 Comments   
Comment by Alex Dean [ 11/Feb/11 ]

Added CodeIgniter details to environment





[DC-763] Timestamp validation does not fail, when missing time in value Created: 24/Jun/10  Updated: 31/Aug/10

Status: Open
Project: Doctrine 1
Component/s: Validators
Affects Version/s: 1.2.1
Fix Version/s: None

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

php 5.2.6 + mysql 5.0


Attachments: File DC763TestCase.php     Text File Timestamp.patch    

 Description   

Doctrine_Validator_Timestamp does not validate correctly, when missing time information in value!

2009-01-20 -> validator returns true, should be false because of the missing time



 Comments   
Comment by Steffen Zeidler [ 31/Aug/10 ]

patch & test





[DC-732] "charset" and "collation" column options cause seeking for a validator Created: 14/Jun/10  Updated: 15/Jun/10

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

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

Doctrine SVN 1.2 r.7676


Attachments: Text File DC-732.patch    

 Description   

If a record has a column defined with 'charset' and/or 'collation' in its options, calling $record->save() triggers exception
PHP Fatal error: Uncaught exception 'Doctrine_Exception' with message 'Validator named 'charset' not available.' in /[...]/lib/vendor/doctrine/Doctrine/Validator.php:56

Fix is trivial, see attached patch

Thank you



 Comments   
Comment by Guilliam X [ 14/Jun/10 ]

oops I had mis-clicked priority to max instead of minor...

Comment by Guilliam X [ 15/Jun/10 ]

Edited the patch with "branches/1.2" as root

I don't provide a test case but they all run without failure after patching





Generated at Thu Oct 23 16:00:19 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.