[TYPO3-team-templavoila] Store configuration (DS, etc.) in other format than XML in database

[Niels Fröhling]

Jigal van Hemert wrote:
>> The conclusion is that there is actually not much XML involved, only the
>> necessary to have a good time with core-flexforms.
> 
> Fabrizio's results read:
> "I profiled a simple single templavoila page with a few fces. (...) While
> profiling there were 350 calls to xml2array, but only 27 different ones."

  Well that's a pretty comon case, even only considering TV-XMLs. Let's say you 
have your content in FCEs and you collect them through CONTENT, then (if there 
are some different FCEs) you end up with a lot of fetches to the same DS/TO-XMLs 
even though the tx_templavoila_flex/tx_templavoila_pi1 are distinct for each 
Page/FCE.

> For a single page 350 calls to xml2array seem like an awful lot...
> I'm going to ask Fabrizio if he happens to have the (27) XML blocks that
> were sent to xml2array. Then we can see how many of those stem from TV.

  I think it not necessarily is related to TV, I guess (I'm so into tt_news) for 
example tt_news which uses Flexform plugin-configuration will produce "an awful 
lot of" xml conversions too.
  Flexforms are pretty common over a broad range of extensions, at least for 
configuration. TV converts exactly 3 XMLs per pi1-call, of that 1 is with very 
high probability empty (TO-localprocessing), makes it let's say 2.01 
conversions. The DSs are not really big, the T3Flexform-results can go bummers 
if you have sections. But if you have a lot of inline-flexform elements the 
entire processing in TV takes magnitutes longer than anything related to 
XML-conversion. I think it's a quite strange idea to speed up TV significantly 
by adjusting the storage format.
  What I guess though is that you can do go from a hierarchical format to a 
planar format. If you look at the code, I don't know maybe 30% of _all_ the code 
in pi1 is related to recursive traversal. If we'd have xml2flat ...
  It doesn't mean 30% of the time is spent on recursion, the fat monster at most 
times is Typoscript.

> Storing data in XML format in a database has a few disadvantages to me:
> - it is not very time efficient to retrieve the data
> - it is (almost?) impossible to do any database selects based on values
> inside XML or have any restrictions on the values (uniqueness, foreign
> keys, etc.)

  We already had some weak inquiries about that mySQL has XML support ... 5.2 at 
least. The problem is that FF by default have non-static number of fields. The 
only thing that would help there would to make aggregate tables for each 
different FF, that's complicated work, and it cost a lot nerves (because the 
core is in chaotic shape). There has to be a FF-registry and so on.
  It's sad we can't rely on native XML support like in DB2 or Oracle ...

> Presenting data in XML form to a human is not a problem. The data can
> easily be converted to and from XML. And because human interaction is
> relatively rare you have performance issues.
> 
> Regards,
> 

  Ciao
     Niels