Hi Joey,
it would be nice when views could take numeric comparisons as filters.
git annex metadata -s length=273.0 john_cage_4_33.mp3
git annex view length<=300
... here is the catch, < and > don't work well in shell, this needs some other Syntax. I think the underlying machinery (using numeric comparisons instead globs) should be quite trivial. Any Ideas about a Syntax?
Further thinking led to the idea to use the test(1) like syntax to filter matches.
I'm a little bit worried about the potential to reinvent SQL, badly.
As shown in your example, once you have ranges, it's natural to also want disjunctions, and then probably parenthesized expressions, and suddenly things are very complicated.
Also, it's important that views remain reversable, so that committing a moved file in a view can unambiguously calculate the new metadata for it. I think that quickly becomes hard when adding these complications.
I'm a little bit worried about the potential to reinvent SQL, badly.
As shown in your example, once you have ranges, it's natural to also want disjunctions, and then probably parenthesized expressions, and suddenly things are very complicated.
Also, it's important that views remain reversable, so that committing a moved file in a view can unambiguously calculate the new metadata for it. I think that quickly becomes hard when adding these complications.
I agree with you that things must stay simple. All what should be done is having the same effects like normal globs but adding arithmetic comparisons to it (could you think about a globbing extension over numeric values?). Then the generated views will have the same properties/semnatic as the normal glob'ed views without other side effects (if you want to go that far, this would even hold true for disjunct, parenthesized and otherwise complex expression).
Example (how it should work, except my bug report 'set metadata on wrong files')
should give ./bar/1/a.txt ./barf/3/c.txt
am I right now than one could
to change the metadata of a.txt, despite the foo=baz and num=2 fields where initially filtered out when creating the view? If this assumption is true then having arithmetic filters, no matter how complex they are won't change the existing semantics over what globs do.