[TYPO3-mvc] Domain model records without pid-column

[Thomas "Thasmo" Deinhamer]

Hello!

I think another reason for which you have to define a storage pid, was 
the restriction on selecting records of a single, configured website if 
you have more than one website configured in the TYPO3 installation.

Otherwise the repository method 'findAll' would return all records of 
all websites configured in the TYPO3 installation. So, either Extbase 
takes care of fetching all objects of a single website (or all if 
configured) or/and it's using the storage page.

And just fyi, at present Extbase does care about the storage page when 
retrieving objects via repository, but it does NOT care about storage 
page when retrieving objects via object property like 
$blog->getAllPosts(); this will fetch all posts, regardless on which 
page they are stored, either on the same domain or on any other in the 
TYPO3 installation.

Imho it's good to have a storage page set all time. But at present it's 
a bit unclear and confusing how it all works. Maybe there should be 
seperate page ids for reading and storing objects, or they should even 
be setable/unsetable via API before querying objects.

Thomas


Am 19.05.2010 22:53, schrieb Felix Oertel:
> Hi,
>
> Am 18.05.10 16:47, schrieb Sebastian Kurfürst:
>> Can we somehow see in TCA if a table has a PID column or not?
>
> Unfortunately we cant't ...
>
>> In case a table has no PID column, we just make it work.
>
> While I totally got messed up and looked around the dbal source for
> about 45 minutes, gathering info about the PID handling (which - yes - I
> somehow confused with the default_sortby thing *g damn it!) I recognized
> that it's not important if a table has a pid column or not.
>
> In normal pi-based extensions as well as dbal as well as
> typo3/mod/web/list the PID is not configured from the outside but the
> logic is implemented. the running code dicides wether it wants to grab
> stuff from one page or all ...
>
> the pid is something we are in control of and what is not given from TCA
> or anything else. we should respect pid if the user defines storagePID
> and just forget about it, if the user does not ...
>
> IMO the right solution would be to move the parameter "storagePid" from
> tx_plugin.persistence.storagePID to
> tx_plugin.persistence.[fullClassName].storagePID so that the developer
> may decide for every table wether he wants to use PID or not. if the
> storagePid is not defined, we just don't care for pid at all.
>
> As PID is the default pid-column, I would suggest if he wants to use it
> and defines it in TS he has to take care for it's existence himself.
>
> when trying to map external tables into extbase (like dennis tries with
> sys_lockedrecords) you may just skip the pid and extbase would not care
> for that.
>
> what do you think?
>
> regards, foertel
>
> PS: to stay compatible we could keep tx_plugin.persistence.storagePID
> and use it for all _plugin-internal_ tables which don't have own
> storagePID set. but do we really need
> config.extbase.persistence.storagePID? i don't think this is an option
> to be used extbase-wide among all installed extensions ...