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

[Dan Osipov]

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
>