Smart Tag Albums with OR in WHERE

[nickelsound]

The Tag Albums work with AND among tag names. I'm not sure if it is on purpose but I would welcome also an ability to define tag names with OR in the WHERE condition. To join more tags together into a Smart Album.

[ildyria]

Yes, we already had this discussion on gitter: https://gitter.im/LycheeOrg/Lobby?at=5f4e11c6dfaaed4ef5232aa3

But this basically implies to define a sort of grammar.

[Sesshoumaru-sama]

I would also like to see a simple syntax solution where you can can specify how your album works. To keep the change non-breaking:

1) We could say that if a tag has prefix "-" images with it will be excluded from the match list. Example (show my all anime images except the ecchi ones): anime,-ecchi,-hentai

2) If a tag has the prefix "^" it is conditional, so it can be there, but it must not be: Example (show anime or manga images): ^anime,^manga [in contrast to AND which would remain: anime,manga]

This is the minimum which should be possible. Adding some fancy syntax with brackets, if somebody needs is, could be added later. The code for the above change would be rather small.

[kamil4]

I'm not wild about the suggested syntax, especially ^ for the logical or since it has a different use in regular expressions or in language such as C; couldn't we simply use OR for that purpose?

In principle though, I think it's a valid suggestion, and I agree that it's probably not a lot of work to implement it. I have no short-term plans to work on it myself though, and I don't think @ildyria has either. Perhaps @Aleshus, who contributed this feature (see #704) would be interested. We also welcome external contributions, so if you feel up to the task, by all means go ahead, develop it and submit a pull request.

[ildyria]

I have no plan to work on this in a near future and would rather focus my free time on the livewire part. That being said:

• - for negation is logical :+1:
• ^ for or is not that great as pointed out by @kamil4 as it might mean beginning of a regex or XOR in C, I would rather see $ as it is less ambiguous at the beginning of a word.

[Sesshoumaru-sama]

I would have preferred to use "+" for AND and without any prefix is OR. But that would be a breaking change. I am software developer and I used to made the experience that most people don't like regex, even if I personally would go hardcore for RegEx support. There is also nothing wrong with using AND and OR and NOT togather with brackets. I have quite some experience with creating pseudo-script languages and thus a got a lot customer feedback.

If I get into frezy mode and need some relaxation from my customers, then I could implement at least a suggestion. It would hopefully one be one method, where the tag matching happens, and thus has to be improved.

[ildyria]

I would have preferred to use "+" for AND and without any prefix is OR. But that would be a breaking change.

Not necessarily as long as you add a migration which makes the conversion.

[Aleshus]

Yes we talked about this. When I though about it I prefered that (star) prefix will be for mandatory tags (photo have to have this tag) and +(plus) prefix for optional tags, but photo must contain at least one defined +tag (if there is some). Default is so star is optional and tag could be defined without it.

Examples: +summer, +spring will find photos from summer or spring *summer, +fred, +laura - will find Freds and Lauras photos from summer summer, sea, +simon, +monica - summer sea photo with Simon or Monica or together.

This was an idea when I worked on it. Finally I have never needed anything else than actual implementation :)

[ildyria]

@nagmat84 what is your opinion on this issue? :laughing:

[nagmat84]

You mean because I am such a big fan of tag albums and want to send them to hell? :rofl: (See #1141).

In principle, it would be possible to have to kinds of tag albums, an OR-type and an AND-type. But I fear that this will very soon lead to the question whether it would be possible to have tags albums which support a custom query string. (I believe such an issue has already been filed.) However, despite my general rejection against tag albums I would refuse support for arbitrary, custom query strings even more. The latter would not allow to eagerly fetch covers of a collection of tag albums. In order to eagerly fetch the covers for a sequence of tag albums we must compile a single SQL query which returns a table of covers with one row per tag album. This requires that the queries for covers of tag alums are structurally identical. Otherwise they cannot be combined into one query.

Long story short, we could add support for tag albums of the AND-type and of OR-type and treat both types differently. But really? :frowning_face:

[kamil4]

Honestly, I think the focus should be on providing this sort of functionality in Search. Ideally, tag albums should just be "saved searches". No, I don't know what that means, either. But it's always struck me as odd that we present this functionality as albums and especially that we store them in the DB as such. Maybe there should be a "Saved Searches" smart album or something, where they are kept (and presented as sub-albums? As photos? As an entirely new kind of clickable object? Not sure)...

This probably belongs better in #1141. I owe you a response there anyway; I've just been too busy with my day job and the kids. Maybe later today or tomorrow...