i18n problem if all fields are in translation table

[Steffen]

If using a simple schema where all fields (execpt the id) are stored in the translation table, doctrine fails saving this object. The translations however are saved, but with "NULL" id.

schema:

---
Test:
  actAs:
    I18n:
      length: 5
      fields: [title, content]
  columns:
    title: string(255)
    content: string

Therefore the i18n behavior is currently completely disfunctional for fully translated objects.

[Garfield-fr]

Adding test coverage: Rev 4688

[Steffen]

Testcase added by Garfield-fr in [4688]. Many thanks.

[Garfield-fr]

Or use this syntax to insert the record:

$r = new Test();
$r->state('TDIRTY');
$r->Translation['fr']->title = 'Titre en français';
$r->Translation['en']->title = 'Title in english';
$r->save();

[Steffen]

Ok, tested and works.

Still I would consider this as a workaround. I'll try to look into what is done differently if state is manually set to TDIRTY.

[Steffen]

So ... I looked a bit into it, and it seems, that the Translation containing object is not notified of the changes made to it. So the Object stays in TCLEAN state since we haven't touched any of its direct properties.

[guilhermeblanco]

This is the expected behavior and we cannot change it due to BC.

We describe this behavior in the manual: http://www.phpdoctrine.org/documentation/manual/0_11/?one-page#component-overview:record:saving-a-blank-record

Marking the ticket as wontfix.

[Steffen]

Well actually the expected behavior is, that the record is saved if I change its properties.

I personally think, that in the described case, the "state" logic should stay in doctrine because currently it shows a faulty behavior. Especially, because the Translation objects are properly saved, but lack an ID so doctrine produces unaccessible clutter in the database.

Also i don't think the BC issue counts here, because existing projects, which workaround the current behavior setting the state manually to TDIRTY, wouldn't be affected if the state would be set by doctrine redundantly.

Also with the upcoming 1.0 release this would be the perfect time to change this because this is a major feature release which may break BC even in this case it wouldn't.

As an approach: Maybe the child Translation objects here (or the Collection whatever suits best) could look if the containing object is still in state "TCLEAN" and change the state to "TDIRTY" so the relation can be saved properly.

Please rethink this.

[romanb]

Concerning BC: Code that previously relied upon the fact that if a new (empty/unmodified) object is saved nothing happens may get unwanted INSERTs. So much for BC.

Concerning the issue itself, you're right, this should be changed, the question remains when.

[Steffen]

romanb: Let me put it this way: Code which currently relies on the fact you stated and where the new (empty/unmodified) object contains a collection of new but modified objects (like Translations) the object containing this collection is not INSERTed but the Translation objects are. But because the "parent" object isn't put to the DB and therefore has no unique ID the Translations are INSERTed to the DB without the foreign key.

So the issue should be solved the one or the other way: - Not saving the "child" objects to the DB if the "parent" isn't INSERTed or - Saving the "parent" object if it contains "children" which are about to be saved regardless if othe properties of the object have been modified

Maybe it's a design desicion.

To the "when" question: as stated above ... the major releases are always a good time to change a behavior.

[romanb]

We decided to address this for the 1.0 release. We concluded that the current behavior is plain wrong. When calling save() on a transient instance the user is asking Doctrine to make this instance persistent. Ignoring this request is wrong behavior. Therefore the TCLEAN state will no longer be ignored in save() operations. We hope that the bc issues will be minor.

You can expect that this will happen soon.

[romanb]

Fixed in changeset 4716. TCLEAN objects are now persisted.

[anonymous]

Milestone New deleted