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

Mathias Schreiber [TYPO3] mathias at typo3.org
Thu Oct 30 15:47:10 CET 2008


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

-- 
T3A AM
Rocking TYPO3 since 3.1b1


More information about the TYPO3-project-dam mailing list