[TYPO3-dam] [TYPO3-dam-devel] DAM, slow queries and DBAL (moved from team.dam)

[Uschi Renziehausen]

Hello Mattes and the rest

I am more or less sure that we will need another 4 weeks from now on for
a) writing the docs (which causes a lot of headaches)
b) fixing some issues that we then will be able to document or even do 
not need to document anymore, because they are obvious.

So I would appreciate a cleanup of the sql-mess very much :-)

Prosit, Uschi

ben van 't ende [netcreators] wrote:
> Heyla Mattes,
> 
> We have had some ups and downs making the documentation also timewise 
> and as Uschi puts it "every line I write adds another question". Can't 
> you just make a patch for it? You guys have been working on it this past 
> time, not? We are doing our collective best to get the doc out, but from 
> experience I can say it could take longer then 2 weeks, but I hope no 
> longer then 4.
> 
> gRTz
> 
> ben
> 
> Dan Osipov wrote:
>> I don't have the exact date for the release. Team?
>>
>> Dan Osipov
>> Calkins Media
>> http://danosipov.com/blog/
>>
>> Mathias Schreiber [TYPO3] wrote:
>>> Dan Osipov schrieb:
>>>> Mathias Schreiber [TYPO3] wrote:
>>>>> Dan Osipov schrieb:
>>>>>> First - wrong list to discuss this. It should be posted to the 
>>>>>> t.p.dam
>>>>>
>>>>> umm... so you say that substantial and needed changes to the DAM 
>>>>> core are on the same level as
>>>>> - how do I get categories from dam?
>>>>> - install problems?
>>>>> - looking for plugin doing A, B or C from DAM records?
>>>>>
>>>>> If so, please explain the difference between the two lists.
>>>>> I understood it as:
>>>>> - Project: People asking for features, help and support
>>>>> - Team: Talking to the people who WORK on the DAM
>>>>
>>>> Team list is like the core list - it's for patches needed to be 
>>>> approved. All other discussion goes in the project list.
>>>
>>> ack
>>> Would make sense to have limited access maybe.
>>>
>>>>>> Second - I have no opinion on the views/no views issue, so I'm for 
>>>>>> anything that improves performance. But this would be a radical 
>>>>>> change to the DAM, and would have to be implemented in 1.2
>>>>>
>>>>> It is a change to the querybuilder which will feel just like it 
>>>>> does now (except it will work on DAM instances larger than "woaa, 
>>>>> got my 100 holiday pictures in DAM").
>>>>>
>>>>> I call this problem a blocker, since it stops DAM functionality AND 
>>>>> blocks up all DAM requests to the database until the query 
>>>>> execution has been finished.
>>>>
>>>> As someone who runs a DAM installation with 2000 new items daily, I 
>>>> understand the concern. However, I don't see this as a blocker - 
>>>> since its only one functionality that's affected.
>>>
>>> I might have a very narrow perspective on DAM, but to me main purpose 
>>> is (or at least was when Rene started working on the basics for 
>>> volkswagen in 2003 (as we were involved in the process)):
>>> - index assets
>>> - categorize assets (for faster lookup of things)
>>> - unify asset usage throughout the site
>>> - make collections available to the FE
>>>
>>> The whole collection thingy is based on a potential blocker, I get 
>>> quite a bad feeling postponing this issue too far.
>>>
>>>>>> I noticed some other file operations that need improvement, and 
>>>>>> was going to work on them after 1.1 is released.
>>>>>
>>>>> What's the timeline for the roadmap then?
>>>>> Plus:
>>>>> If we supply the patch in the near future what's the holdup?
>>>>
>>>> Well, if you supply the patch, we can look at how much change and 
>>>> testing is required, and based on that include it either in 1.1 or 1.2
>>>
>>> ok
>>>
>>>> There are a couple bugs outstanding for 1.1 - and they need approval 
>>>> in this list. Documentation is the major task that needs to be done, 
>>>> and it is in process right now. So 1.1 is nearly complete.
>>>
>>> No offense, but "nearly" doesn't really show up on my calendar. :)
>>> I don't need a certain date but at least a range of time where the 
>>> release is planned (+/- two weeks) so we can plan resources on the 
>>> collection issue.
>>> If we're talking 2 weeks from now, we would write the whole thing as 
>>> a set of xclasses because I am not sure if testing can be done in 
>>> such a short timeframe.
>>> If we're talking 4 weeks or more we would dig into the source 
>>> directly (massively speeding up the process of course) and supply a 
>>> patch earlier.
>>> It's kinda hard to plan anything without knowing when 1.1 release 
>>> will be or 1.2 release will be, so bear with me about being so pushy.
>>>
>>> all the best
>>> mathias
>>>
> 
>