Re: [PATCH 3/3] test: ruby: simplify basic tests

2021-06-07 Thread Felipe Contreras
On Mon, Jun 7, 2021 at 6:53 PM David Bremner  wrote:
>
> Felipe Contreras  writes:
>
> >>
> >> Is this assuming that the sort order in the CLI is the same as in the
> >> library / bindings? that seems a bit fragile if so.
> >
> > Both the CLI and the bindings are using the same libnotmuch library.
> > If neither of them specify a sort order, the default sort order of
> > libnotmuch would be used (I presume). Exactly the same order I would
> > get if I write a C program that uses libnotmuch and doesn't specify
> > any order.
> >
> > Why would the CLI specify an order the user didn't specify to libnotmuch?
>
> I guess the point is that the CLI is not required to track the library
> precisely, so even if it is a bit theoretical, this change does
> introduce some fragility / technical debt into the test suite.
>
> For better or for worse, the API does not document a default sort order,
> so assuming any particular sort order is probably a mistake. I can
> imagine a future database backend where the "UNSORTED" order is actually
> non-deterministic. If we were to document a default sort order, UNSORTED
> might make the most sense as a default, as it's the highest performance
> (more or less by definition).

We could have test_ruby_unordered and sort both the expected and
actual files to ensure the tests don't break if in the future the
default order changes. But personally I don't see much point in
complicating the tests preemptively. I would rather worry when the
time comes, which might be never.

-- 
Felipe Contreras
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 3/3] test: ruby: simplify basic tests

2021-06-07 Thread David Bremner
Felipe Contreras  writes:

>>
>> Is this assuming that the sort order in the CLI is the same as in the
>> library / bindings? that seems a bit fragile if so.
>
> Both the CLI and the bindings are using the same libnotmuch library.
> If neither of them specify a sort order, the default sort order of
> libnotmuch would be used (I presume). Exactly the same order I would
> get if I write a C program that uses libnotmuch and doesn't specify
> any order.
>
> Why would the CLI specify an order the user didn't specify to libnotmuch?

I guess the point is that the CLI is not required to track the library
precisely, so even if it is a bit theoretical, this change does
introduce some fragility / technical debt into the test suite.

For better or for worse, the API does not document a default sort order,
so assuming any particular sort order is probably a mistake. I can
imagine a future database backend where the "UNSORTED" order is actually
non-deterministic. If we were to document a default sort order, UNSORTED
might make the most sense as a default, as it's the highest performance
(more or less by definition).
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 3/3] test: ruby: simplify basic tests

2021-05-23 Thread Felipe Contreras
On Sun, May 23, 2021 at 7:32 AM David Bremner  wrote:
>
> Felipe Contreras  writes:
>
> > We don't need to check for the order here, that is done in another test.
> >
> > Signed-off-by: Felipe Contreras 
> > ---
> >  test/T395-ruby.sh | 12 
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/test/T395-ruby.sh b/test/T395-ruby.sh
> > index e828efed..9298bc9e 100755
> > --- a/test/T395-ruby.sh
> > +++ b/test/T395-ruby.sh
> > @@ -20,21 +20,17 @@ test_ruby() {
> >  }
> >
> >  test_begin_subtest "compare thread ids"
> > -notmuch search --sort=oldest-first --output=threads tag:inbox > EXPECTED
> > +notmuch search --output=threads tag:inbox > EXPECTED
> >  test_ruby <<"EOF"
> > -q = db.query('tag:inbox')
> > -q.sort = Notmuch::SORT_OLDEST_FIRST
> > -q.search_threads.each do |t|
> > +db.query('tag:inbox').search_threads.each do |t|
> >puts 'thread:%s' % t.thread_id
> >  end
> >  EOF
> >
>
> Is this assuming that the sort order in the CLI is the same as in the
> library / bindings? that seems a bit fragile if so.

Both the CLI and the bindings are using the same libnotmuch library.
If neither of them specify a sort order, the default sort order of
libnotmuch would be used (I presume). Exactly the same order I would
get if I write a C program that uses libnotmuch and doesn't specify
any order.

Why would the CLI specify an order the user didn't specify to libnotmuch?

-- 
Felipe Contreras
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 3/3] test: ruby: simplify basic tests

2021-05-23 Thread David Bremner
Felipe Contreras  writes:

> We don't need to check for the order here, that is done in another test.
>
> Signed-off-by: Felipe Contreras 
> ---
>  test/T395-ruby.sh | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/test/T395-ruby.sh b/test/T395-ruby.sh
> index e828efed..9298bc9e 100755
> --- a/test/T395-ruby.sh
> +++ b/test/T395-ruby.sh
> @@ -20,21 +20,17 @@ test_ruby() {
>  }
>  
>  test_begin_subtest "compare thread ids"
> -notmuch search --sort=oldest-first --output=threads tag:inbox > EXPECTED
> +notmuch search --output=threads tag:inbox > EXPECTED
>  test_ruby <<"EOF"
> -q = db.query('tag:inbox')
> -q.sort = Notmuch::SORT_OLDEST_FIRST
> -q.search_threads.each do |t|
> +db.query('tag:inbox').search_threads.each do |t|
>puts 'thread:%s' % t.thread_id
>  end
>  EOF
>  

Is this assuming that the sort order in the CLI is the same as in the
library / bindings? that seems a bit fragile if so.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org