Hi Jeremy

Perhaps it's better to check @opts inside select_sql?

2017-07-12 22:05 GMT+03:00 Jeremy Evans <[email protected]>:

> On Wednesday, July 12, 2017 at 11:55:17 AM UTC-7, Jeremy Evans wrote:
>>
>> On Wednesday, July 12, 2017 at 10:36:20 AM UTC-7, [email protected]
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, July 12, 2017 at  UTC+3, Jeremy Evans wrote:
>>>>
>>>> Hi Jeremy, our admins gave me access to our dev servers, but specs fail
>>>>> even for yesterday's master.
>>>>>
>>>>> I've run test suite on three different servers with similar results,
>>>>> like
>>>>>
>>>>> 736 runs, 3442 assertions, 21 failures, 214 errors, 28 skips
>>>>>
>>>>> Not sure if it is issue with my setup.
>>>>>  I've made a gist with logs from each run,
>>>>> https://gist.github.com/timon/7a4affab68e4b0b1cd3ec8d330c1b369
>>>>>
>>>>>
>>>> I probably should have mentioned this earlier, but the oracle adapter
>>>> tests require the :autosequence option.  If you weren't using that before,
>>>> could you try rerunning the specs with that option and see if it fixes the
>>>> issue?  If that doesn't fix it, I'm assuming the failures are either due to
>>>> Oracle version or configuration differences.  Here's what I get when
>>>> running the specs using the older Oracle VM I currently test with (server
>>>> version 11020002):
>>>>
>>>> 759 runs, 10604 assertions, 0 failures, 0 errors, 28 skips
>>>>
>>>
>>> Yes, that did the trick.
>>> On Oracle 11 all tests pass.
>>>
>>> On Oracle 12, after I moved limit method before lock (having them after
>>> lock produced invalid queries), I have two failing tests, which I
>>> cannot figure out:
>>> Sequel::DatabaseError: OCIError: ORA-02014: cannot select FOR UPDATE
>>> from view with DISTINCT, GROUP BY, etc.
>>>
>>> Lines that fail are spec/integration/dataset_test.rb:180
>>> and spec/integration/model_test.rb:235
>>>
>>
>> With the current master branch, all tests not explicitly skipped pass in
>> both Oracle 11 and 12 (yay!).   I'll have to test your branch and see if I
>> can figure out what the issue is.  It's possible we won't be able to use
>> the new offset syntax in certain cases if it causes problems.
>>
>
> Oracle doesn't like that offset syntax when used with locking.  This
> appears to work around the problem and make all tests pass:
>
>       def supports_fetch_next_rows?
>         server_version >= 12000000 && !@opts[:skip_locked] && !@opts[:lock]
>       end
>
> Can you include that fix, rebase and squash your changes into a single
> commit, and then submit it as a pull request to jeremyevans/sequel?
>
> Thanks,
> Jeremy
>
> --
> You received this message because you are subscribed to the Google Groups
> "sequel-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/sequel-talk.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Reply via email to