[TYPO3-core] RFC: #11168: Wrong substitution of ###THIS_UID### in t3lib_loaddbgroup.php

[JoH asenau]

> MM_table_where isn't used in core, also nit in DAM and their
> extensions which uses MM very much.

So?

> The whole concept is a bit clouded. MM_table_where is a free
> configuration for TCA which is defined as "additional where clause for
> MM". So
> 1) naming is wrong, should be MM_table_andWhere
> 2) you should use it like 'MM_table_where' => ' AND
> tx_dam_mm_cat.uid_foreign!=###THIS_UID###' or simular.
>
> Adding AND here would break other extensions having this defined.

So what?!
It is still a bug of a core function which might have made this workaround
necessary in those extensions.

> 3) totally underdocumented, missing any "real" example. From the
> naming
> you may think, it's simular to "foreign_table_where" which doesn't use
> AND, but this is wrong.
>
> Looking to extbase, they also use it the wrong way, look to
> Datamp_testcase where they define
> 'MM_table_where' => 'WHERE 2=2',
>
> I will report it in extbase list.
>
> Joey, please have a look to your tagpack where you use it. Add the AND
> in your extension and everything should work fine.

Adding this AND in my extension is not necessary anymore, because we are
using an own library now which is handling the stuff correctly, so no, I
won't ;-)

But if you read my proposal carefully you might have noticed that it says:
Check(!) for an existing AND and if(!) there is none add it, because it is
necessary.
I have to admit, that the patch I uploaded to the bugtracker didn't do that,
but this would be the way to go.

> 4) Comparing loaddbgroup to the
> t3lib_beFunc::exec_foreign_table_where_query only replacing
> ###THIS_UID### might be too less, there you see also other
> placeholders like ###CURRENT_PID###, ###THIS_CID###,
> ###STORAGE_PID### etc.
> maybe we need real usecases to see what makes sense here, but for me
> it looks bit inconsistent.

Still it is a bug that should be fixed, no matter how it might look.
This is not about writing beautiful code but about fixing a bug.

If you take a look at the lines 286, 301 and 304 you will see that 301 is
the only one missing an AND.
So it would be very consistent to put it in here and make sure that
MM_is_foreign, MM_table_where and MM_match_fields are working the same way.

> Sry for writing long story, but i think this shows how it works. As
> nobody else complaint i think this is used very seldom. Anybody who
> configured MM in TCA know the many hours of try&error until
> configuration works as expected. Don't misunderstand, for core cases
> it works, but core has no real MM defined, this is something for
> extensions, and of course extbase which has to deal with that in
> datamapper.

For me MM worked just within a few minutes, so no try & error until it
worked as expected.
I guess this might be due to the fact that I did it the right way, which
just left this one small bug as a source of the problem in certain
scenarios.

I will provide a patch containing the check if no one complains.

BTW: The fact that the core still uses CSV "relations" instead of real MM is
one of the sources for the bad overall performance of the system and the
reason for lots of workarounds. So we should get rid of it as soon as
possible and try to make use of the function the DB provides. After all this
is why it is called a relational database, isn't it?

Cheers

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com