UniqueObject Validators doesn't work if you give the column a different name, than the fields name.

[DennisDobslaf]

UniqueObject Validators doesn't work if you give the column a different name, than the fields name.

So, if you have an user entity with id as identifier and name the column like 'user_id' (so, the webform also contains a field names 'user_id' the validator will fail at`

if (!isset($context[$columnName])) {

because, there is no 'id' (but 'user_id') in the form.

So, as renaming columns is a supported behaviour shouldn't the UniqueObject validator rely on the choosen/given columnName?

If have a working example here, but don't know, if it is correct in all ways...
Could make a pull request for that.

[Ocramius]

This seems like a design flaw.

@UFOMelkor do you think we can make the UniqueObject validator rely solely on $value (as an array) and on $context only if the user wants that?

[DennisDobslaf]

In my temporary solution, I grap the column name of the identifier fields.
It works so far ;-)

Have a look at:

https://github.com/DennisDobslaf/DoctrineModule/blob/master/src/DoctrineModule/Validator/UniqueObject.php

2014-02-10 Marco Pivetta notifications@github.com

This seems like a design flaw.

@UFOMelkor https://github.com/UFOMelkor do you think we can make
$context optional?

Reply to this email directly or view it on GitHubhttps://github.com//issues/377#issuecomment-34697962
.

[DennisDobslaf]

I don't like the 'columnName' index, as it is kind of a magic constant. But
found no other (quick) solution for me :(

2014-02-11 Dennis Dobslaf dennis.dobslaf@gmail.com

In my temporary solution, I grap the column name of the identifier fields.
It works so far ;-)

Have a look at:

https://github.com/DennisDobslaf/DoctrineModule/blob/master/src/DoctrineModule/Validator/UniqueObject.php

2014-02-10 Marco Pivetta notifications@github.com

This seems like a design flaw.

@UFOMelkor https://github.com/UFOMelkor do you think we can make
$context optional?

Reply to this email directly or view it on GitHubhttps://github.com//issues/377#issuecomment-34697962
.

[Ocramius]

@DennisDobslaf doctrine deals with field names - column names are a low level problem that you shouldn't deal with, so that's absolutely the wrong fix/approach.

[DennisDobslaf]

Ok, understood this. I could change my 'user_id' into 'id', but that's not
a final solution either. ;-)

2014-02-11 Marco Pivetta notifications@github.com

@DennisDobslaf https://github.com/DennisDobslaf doctrine deals with
field names - column names are a low level problem that you shouldn't deal
with, so that's absolutely the wrong fix/approach.

Reply to this email directly or view it on GitHubhttps://github.com//issues/377#issuecomment-34703322
.

[UFOMelkor]

Sorry for the long delay, I was on holidays.

@Ocramius
I used the $context parameter because it's also used by some zf2 classes (see Zend\InputFilter\Input, Zend\Validator\ValidatorChain and Zend\Validator\Identical).

[Ocramius]

I know where it is used, I just really dislike that approach :P

[UFOMelkor]

:-D

I'm fine with using $context only optional, but I'm not sure whether this will change the reported issues. IMHO we need especially a little more documentation for the UniqueObjectValidator.

One questions because I'm doing to much java and to less zf2 at the moment: For supporting Zend\Form we need the $context, don't we?

[Ocramius]

@UFOMelkor the other way would be to have a fieldset for multi-field values...

But yes, $context seems to have this necessary evil. What is still broken is indeed documentation about the fact that it is opinionated.

[UFOMelkor]

Ok, I will look on this and send a PR :-)

[DennisDobslaf]

What about this approach(!)

https://github.com/DennisDobslaf/DoctrineModule/blob/master/src/DoctrineModule/Validator/UniqueObject.php

Usage is like

$uniqueEmailValidator = new UniqueObject(array(
'object_repository' => $userRepository,
'fields' => array('email'),
'object_manager' => $this->getObjectManager(),
'token' => array(
'id' => 'user_id'
),
));

[Bilge]

I don't know why that PR is referencing this issue because not only does that PR not address this issue in any way, it also breaks BC as an added bonus.

I still receive the Expected context to contain id exception whether or not I elect to use_context in 0.8.1.

The fallacy seems to be assuming that the entity's identifier field will be provided by the form. I'm sure this is possible if you're editing an existing entity but if you're adding a new entity with a unique field that is different from the identifier field then the identifier will not be available since it is auto-generated by the DB.