[TYPO3-mvc] Respect storage page ignored on object properties

[Thomas "Thasmo" Deinhamer]

Cancel that - your patch works. I'm not sure why, and how this magic 
changes the resultset, but it actually works and only returns 
property-objects whichare stored on the configured storage pages.

Thanks a lot!

This works as long as you a) apply the patch of Jochen and b) use 
setRespectStoragePage(TRUE) in the DataMapper in the method 
getPreparedQuery().

Imho this is a good patch and should be commited to trunk.

Thanks a lot for the help!
(In the the end you changed 1 line, more [or less] - and I tried for 
hours - that's just insane!! xD)

Thomas

PS: I'm going to attach your patch to the ticket on Forge.
http://forge.typo3.org/issues/show/7274

Am 28.05.2010 00:51, schrieb Thomas "Thasmo" Deinhamer:
> Hello Jochen, thanks a lot for your reply!
>
> Applying your patch doesn't change the resultset.
> The query which is missing the storage page
> condition is this, where 'tx_hypestore_relation_category_product' is a
> MM table:
>
> ==================================================
> Array
> (
> [keywords] => Array
> (
> )
>
> [tables] => Array
> (
> [tx_hypestore_relation_category_product] =>
> tx_hypestore_relation_category_product
> )
>
> [unions] => Array
> (
> [tx_hypestore_domain_model_product] => LEFT JOIN
> tx_hypestore_domain_model_product ON
> tx_hypestore_relation_category_product.uid_local =
> tx_hypestore_domain_model_product.uid
> )
>
> [fields] => Array
> (
> [tx_hypestore_relation_category_product] =>
> tx_hypestore_domain_model_product.*
> )
>
> [where] => Array
> (
> [0] => tx_hypestore_relation_category_product.uid_foreign = ?
> )
>
> [additionalWhereClause] => Array
> (
> [0] => (tx_hypestore_domain_model_product.type='default' OR
> tx_hypestore_domain_model_product.type='apparel' OR
> tx_hypestore_domain_model_product.type='book' OR
> tx_hypestore_domain_model_product.type='car')
> [1] => tx_hypestore_domain_model_product.deleted=0 AND
> tx_hypestore_domain_model_product.hidden=0 AND
> tx_hypestore_domain_model_product.starttime<=1274999580 AND
> (tx_hypestore_domain_model_product.endtime=0 OR
> tx_hypestore_domain_model_product.endtime>1274999580) AND
> (tx_hypestore_domain_model_product.fe_group='' OR
> tx_hypestore_domain_model_product.fe_group IS NULL OR
> tx_hypestore_domain_model_product.fe_group='0' OR
> (tx_hypestore_domain_model_product.fe_group LIKE '%,0,%' OR
> tx_hypestore_domain_model_product.fe_group LIKE '0,%' OR
> tx_hypestore_domain_model_product.fe_group LIKE '%,0' OR
> tx_hypestore_domain_model_product.fe_group='0') OR
> (tx_hypestore_domain_model_product.fe_group LIKE '%,-1,%' OR
> tx_hypestore_domain_model_product.fe_group LIKE '-1,%' OR
> tx_hypestore_domain_model_product.fe_group LIKE '%,-1' OR
> tx_hypestore_domain_model_product.fe_group='-1'))
> [2] => tx_hypestore_domain_model_product.sys_language_uid IN (0,-1)
> )
>
> [orderings] => Array
> (
> [0] => tx_hypestore_relation_category_product.sorting_foreign ASC
> )
>
> [limit] => Array
> (
> )
>
> )
> ==================================================
>
> As you can see inside "[additionalWhereClause]" the condition for the
> storage pages are still missing.
>
> Also note, that the actual table beeing queried is the MM table, but in
> the end the query should fetch all fields of the table
> 'tx_hypestore_domain_model_product'.
>
> To clarify my situation a bit more:
>
> There are global objects of class 'Category' which are stored in a
> seperate sysfolder. Then I got several page-trees, which all relate to
> one domain each. Each tree/domain has it's own sysfolder with objects of
> class 'Product' which can be assigned to the global categories. The
> content plugin - lets call it 'Shop' - is inserted on every of the
> trees/domains seperately and SHOULD display all categories and the
> products within - but ONLY the products which are stored on the same
> tree/domains.
>
> Let's expect this pages:
>
> [10] Global Categories
> [20] Domain J
> [21] Products J
> [22] Shop J
> [30] Domain R
> [31] Products R
> [32] Shop R
>
> When I now insert the Shop plugin on page [22] and configure the storage
> page to be "21,10" then it will list all categories BUT also the
> products from this categories which are stored on [31] which is imho bad
> - I only want to display products from [21].
>
> This only happens when using $category->getProducts() but NOT when using
> the product repository. But I have to use the object property to loop
> throu all categories and (sub-loop) all products of each category.
>
> Hopefully it's clear now what the problem is, and I really think that
> the actual situation is not the best. If someone wants to show ALL
> related objects of one object, he should configure the storage page to a
> global parent page and set recursive to 99 to get all objects returned.
> I think setting/defining storage pages is a planned process when
> creating websites, so the sysfolders/pages where objects are stored, are
> well known from beginning - it's not like someone doesn't know the page
> uids beforehand and thus wants to return the objects without respecting
> the storage pages. But if so, someone should just define a
> superglobal/root page uid as storage page.
>
> I'd really like to see this fixed and I would provide a patch, but if
> I'd ever find out how to do it, it will be a mess of a code. So I really
> appreciate your (in sense of you all) help on this.
>
> Thanks a lot,
> Thomas
>
>
> Am 28.05.2010 00:06, schrieb Jochen Rau:
>> Hi Thomas,
>>
>> sorry for jumping into this discussion late. After the the T3CON in
>> Dallas I had to proof read the Extbase/Fluid book first.
>>
>> On 27.05.10 18:31, Thomas "Thasmo" Deinhamer wrote:
>>> Okay, I think I found the place where things are either not yet
>>> implemented or just not working correctly.
>>>
>>> In file 'Typo3DbBackend.php' on line 752 in the method
>>> 'addAdditionalWhereClause' the query settinsg are checked if the storage
>>> page should be set or not. If, then the method 'addPageIdStatement' on
>>> line 802 is called which adds the storage pid restriction. But for MM
>>> tables it won't do this, because there's an if statement, checking some
>>> conditions of the TCA, where MM tables won't pass because they don't
>>> match a specific TCA configuration.
>>>
>>> So I think in the method 'addPageIdStatement' there should be the logic
>>> to check if the table is a MM table, and if so, the origin-table should
>>> be determined and then it's possible to add the correct where clause.
>>>
>>> I'm not 100% sure if this will work, but I think it's the problem when
>>> querying MM tables with a LEFT JOIN, but fetching the fields of the
>>> origin table.
>>>
>>> Any idea how to extend the method to enable a storage page for left
>>> joins?
>>
>> Fetching *related* records ignoring the PID is the intended behavior
>> atm. Somebody must have consciously assigned this object to its parent.
>> So I agree to Sebastian here. But this doesn't mean that we are right.
>> IMO the whole PID topic is worth to be discussed again to improve or at
>> least to clarify the things.
>>
>> The described behavior is determined in the DataMapper in line 357 as
>> you already pointed out:
>>
>> $query->getQuerySettings()->setRespectStoragePage(FALSE);
>>
>> You already changed the argument to TRUE (or uncommented the line). And
>> here you encountered an issue (thanks for that). The PID constraint was
>> not added as it should have been. The issue should be fixed by applying
>> the (hopefully) attached patch. Would you mind to test it?
>>
>> Regards
>> Jochen