Implement new field type

[bigfoot90]

I would propose to implement a custom field type, so you don't have to declare $uuid property explicitly.

Old mapping:

class Entity
{
    /**
     * @ORM\Column(type="string")
     */
    public $targetUuid;

    /**
     * @ODMAdapter\ReferencePhpcr(
     *  targetObject="Document",
     *  referencedBy="uuid",
     *  inversedBy="targetUuid"
     * )
     */
    public $target;
}

New mapping:

class Entity
{
    /**
     * @ODMAdapter\ReferencePhpcr(
     *  targetObject="Document",
     *  referencedBy="uuid"
     * )
     */
    public $target;
}

[bigfoot90]

@ElectricMaxxx ping

[ElectricMaxxx]

@bigfoot90 i can't really follow the idea of that type. I would just implement and own type called uuid, right. But where is is mapping to the type in your example? And where would i get the uuid i have mapped?

Or do i have both then? target is the document and uuid while persisting? I have played with that idea and it sounds sane for me as i have both then: the uuid by $target->getUuid() and the document itself. But i would cause some refactoring in the UoW and the ClassMetadataMapping.

You would have some time to have a look into the code for that and create a PR? But it should be done in the library itself.

[bigfoot90]

@ElectricMaxxx The mapping are inside the type itself.
You have to convert Document to Uuid when persisting convertToDatabaseValue, and
reconvert Uuid to Document when loading convertToPHPValue.

I'm not 100% sure that this work, I have to investigate further.
Perhaps it is more complicated than it seems.

[bigfoot90]

And also I don't know how to manage extra common fields.
Maybe create a proxy class, like doctrine does with lazy loading.

[bigfoot90]

I'm not a Doctrine expert. I've began to study Doctrine internals a few days ago.
Do you have a good guide or link about Doctrine's UoW and ClassMetadataMapping.
Thanks for all.

[ElectricMaxxx]

oh ... i forgot the common fields, which are working on the same way as the identifiers do. The other question would be: is there an equal mechanism on the other implementations? (phpcr-odm @dbu?)

[dbu]

i am not aware of good documentation of the UoW. @Ocramius is working on a stand-alone UoW which should be a lot cleaner than what we currently have - and as a side effect should be able to handle cross-system references without any extra libraries.

i am not familiar with "common fields" of the orm. maybe @Ocramius can help you here?

[Ocramius]

By looking at the initial post (no time to follow all the thread, sorry!) I don't think there should be custom definitions for hopping from ORM to ODM to PHPCR-ODM or such.

If ClassA is mapped in ORM, and ClassB is mapped in ODM, then their association should simply be a generic link, that isn't aware if the underlying communication is from ORM to ODM.

[Ocramius]

If you need a UoW specification, please use https://github.com/Ocramius/ChangeSet/tree/6dd6525b01d633853f0643d872e9c2efc1a82e19/features/unit-of-work

[ElectricMaxxx]

@dbu @Ocramius the thing i was asking fo had been the Type definition of the doctrine-dbal.
The common-field think is a feature of my library, where i define two fields as common (in an Entity and Document), which where synced automatic. Persisting the uuid of a referenced document or the id of an referenced entity is working that way, but not the same as i have an extra mapping for the referencing.

@bigfoot90 was asking for a type defintion to persist the the referenced document of an entity and its uuid in one property. The type would just be responsible for converting uuid->document and back. So the uuid is persisted and i can work with the document behind it, when creating that type. That would work, when i reference an document on an entity. For the other way around i would need the same feature in the phpcr-odm.

[bigfoot90]

@Ocramius Thanks for reference.

@ElectricMaxxx You have centered the point of question. Declaring $targetUuid property in entity is wrong because the Entity has nothing to do with the target's uuid. The target should be instead converted to uuid when you are persisting it to the storage layer.