Re: Last Import patch

[Bengt Thuree <bengt thuree com>]

On Fri, 2006-05-19 at 13:44 +0200, Thomas Van Machelen wrote:
> Hi Bengt,
> 
> Although i think it would be nice to have an import history, i have
> some comments on your patch.

:) Much appreciated :)

> 
> As you can see in your own comments, using tags is not the best way.
> Because you use special tags, you have to implement some kind of
> "exception logic" for them: they cannot be added during import by the
> user, and you have to create them if they do not exist yet.  Next to
> that you have to shift older import tags to higher numbers if you do a
> new import (0 becomes 1, 1 becomes 2,...).  Imagine what this would do
> to performance if your last 5 imports, imported 1000 each.  Things
> would probably become even worse when you have xmp tagging enabled:
> that would cause 5000 photos to be changed on disk.  I fear this might
> take quite a while.

True.
But the shifting is only done in the database and not on the photo
itself. Ok, I cheated a bit there :) Good point though. Not good to
cheat. Since I guess that the photo have __0 instead of __1 which is in
the database after the second import. Hmm.

> 
> > Any comments?
> > Is it overkill with tracking 6 imports?
> > I do think only have the last is not enough though.
> >
> 
> While i do think that 5-6 imports is a nice default, i can easily
> imagine that people want to track _all_ their imports, or only the
> last one.  Either your implementation is too simple, or it is too
> complicated.

:)

> 
> A better approach would be too add 1 or 2 tables to the database.  For
> example one table that keeps track of the imports performed, and
> another one that ties photos to a certain import.

Yes this would definitely speed up the process quite a bit.
But also make it a lot more complicated to use the filter.
For instance: I want to see all photos from the last and second last
import that I have not set a location tag on.
If the import sessions are treated as tags, then everything else falls
very nicely into place. Apart from the fact that you need to treat these
as special tags.
For instance, you also need to extend the Tag database with one extra
column for what to display. Usually the Tag Name and Tag Display name
should be same, but for these "special" tags, you need to know the tag
name (no matter which locale you are using). I know, not a perfect
solution. 
But how should you get the extra Import date table to be treated as
tags, without beeing tags?

> 
> If you do so, you will not have to use any special tags, performing
> new imports will not suffer too much from previous imports and
> querying imports can be come more flexible (for example: give me an
> overview of the last 5 imports, give me an overview of the imports
> performed in the last week or the ones performed in march, ...).
> Also, you wil not have to cope with incrementing the numbers of
> previous imports.

Can not imagine why people would like to know there various imports.
Only the last number of them to be able to handle the tagging a bit
easier. 

> 
> That's it!  I hope to have given a good overview of why i think this
> can be done better.  Give it some dedication, and i think this can
> become very useful.

Yes, very nice overview as well as review of the patch. Much
appreciated. Seems to be a bit more complicated than first attempt :(

> 
> What are other people's comments on this?  Unfortunately my opinion
> still is only an opinion ;-)
As is mine ;)

> 
> Best Regards,
> Thomas
> 

/Bengt