[TYPO3-core] RFC: Bidirectioanl MM relations

[Ingmar Schlecht]

Hi Kasper,

Kasper Skårhøj wrote:
> A vision (not for this patch) is that one day the MM-tables can contain
> additional fields with information that says something about the
> relation. However, that requires quite some changes, among others that
> MM-table relations are not "deleted/created again" as they are now in
> TCEmain. 

We already switched from doing a delete/create-again to an
update/insert-if-not-existing in order to maintain the sorting on the
"other side".

> Further, it would need a change so relations communicated
> to/from TCEmain and TCEforms is more than just a table_uid string.
> Hmm... And finally, such as the T3D format must support it also.

Right. Apart from I guess storing additional information attached to a
relation would need changes to the user interface to comfortably edit
those added infos.

> Anyway, there is one concern: what about the sys_refindex?
> 
> With what you have done I kind of assume that sys_refindex actually
> stores a relation "twice" now. Example:
> 
> pages:1 => MM => pages:2,pages:3
> 
> So, you edit pages:1. The sys_refindex gets updated; the relation to
> pages:2 and pages:3 is registered.
> 
> So, you choose to edit pages:2 now. The relation from pages:1 to pages:2
> is shown, you choose to say add or delete something. During the saving
> in TCemain, the sys_refindex is updated for "pages:2". Will it add the
> reference to pages:1 now?
> 
> If the reference is added, it will be redundant in a sense. We must
> consider it: Should the sys_refindex NOT register the reference when it
> is in fact coming from another record? Or should we let sys_refindex
> understand it as "equal" and register it for both pages:1 and pages:2?

The problem is exactly the way you described it :-)

> What feels right to you?

The best way would be if the refindex offered a way to store the
relation only as one refindex-record but it would automatically appear
on both sides of the relation.

The second best way IMHO is registering the relation only once as a
relation from the local to the forein side. Therefore, when you
add/remove relations while editing the foreign side, it should add or
remove sys_refindex entries for the local side pointing to the record
you're editing.

> Anyway, the more SERIOUS problem with sys_refindex is this: Say you edit
> pages:2 and remove the reference to pages:1. Now pages:1 only points to
> "pages:3". However, in sys_refindex there will still be a reference
> recorded to both pages:2 and pages:3 because when saving pages:2 the API
> call is only made for pages:2 - but it should also be made for any added
> or removed reference!

Yes, this would become a problem if you'd put each relation into
sys_refindex twice, because the local side can't guess from its TCA
config whether there's an opposite field configured for the relation.

> I didn't look at the code, but either this should be done in TCEmain -
> or maybe in sys_refindex. Because when you call sys_refindex to update
> itself it will look for what references was added and which was removed
> and for each we could call itself redundantly of course to update those.
> That would in fact have the most general character.
> 
> I'm willing to implement this for you guys when I get a chance to test
> your work. Currently, I'm on an island for myself since my Mac
> completely refuses any SVN connections with any client application and I
> don't know what to do...

Great. What would you suggest, should we already commit the stuff and
you'll add the refindex stuff later?

cheers
Ingmar