Jeremy-
That worked. Thanks! Updated the gist:
I have 6 remaining dataset tests that are failing. These are the ones I have no
clue about:
rspec ./spec/integration/dataset_test.rb:1332 # Sequel::Dataset DSL support
should work empty arrays with nulls
Generated SQL does not work and not sure what is should look like:
"SELECT TOP 1 (\"A\" != \"A\") AS \"V\" FROM \"A\" ORDER BY \"A\""
1) Sequel::Dataset DSL support should work empty arrays with nulls
Failure/Error: pr[@ds.get(Sequel.expr(:a=>[]))].should == nil
Sequel::DatabaseError:
Sequel::SqlAnywhere::SQLAnywhereException: Syntax error near '!=' on line 1
------
rspec ./spec/integration/dataset_test.rb:1349 # Sequel::Dataset DSL support
should work empty arrays with nulls and the empty_array_ignore_nulls extension
Generated SQL is using (1=0) for the FALSE. I thought I took care of that with
the BOOL_FALSE = 0
"SELECT TOP 1 (1 = 0) AS \"V\" FROM \"A\" ORDER BY \"A\""
1) Sequel::Dataset DSL support should work empty arrays with nulls and the
empty_array_ignore_nulls extension
Failure/Error: pr[ds.get(Sequel.expr(:a=>[]))].should == false
Sequel::DatabaseError:
Sequel::SqlAnywhere::SQLAnywhereException: Syntax error near '=' on line 1
----
rspec ./spec/integration/dataset_test.rb:1459 # Dataset string methods #like
should be case sensitive
SQL looks correct. But, Sybase SQLAnywhere is case insensitive by default, I
believe. Well, we don't set the case sensitivity when we build a DB. How do I
make this work vs the ilike in the SQL?
"SELECT * FROM \"A\" WHERE (\"A\" LIKE 'Foo' ESCAPE '\\') ORDER BY \"A\""
1) Dataset string methods #like should be case sensitive
Failure/Error: @ds.filter(Sequel.expr(:a).like('Foo')).all.should == []
expected: []
got: [{:a=>"foo", :b=>"bar"}] (using ==)
Diff:
@@ -1,2 +1,2 @@
-[]
+[{:a=>"foo", :b=>"bar"}]
---
rspec ./spec/integration/dataset_test.rb:1479 # Dataset string methods
#escape_like should escape any metacharacters
Multiple backslashes (escapes) in the SQL is not working real well with
SQLAnywhere. I actually had to break apart 1 test that had multiple strings it
tested to ones that worked and ones the did not putting those in cspecify. Do I
need to do the same for this one.
"SELECT \"B\" FROM \"A\" WHERE (\"B\" LIKE 'bar\\\\\\%' ESCAPE '\\') ORDER BY
\"B\""
1) Dataset string methods #escape_like should escape any metacharacters
Failure/Error:
@ds.filter(Sequel.expr(:b).like(@ds.escape_like('bar\\%'))).select_order_map(:b).should
== ['bar\\%']
expected: ["bar\\%"]
got: ["bar\\%", "bar\\.."] (using ==)
---
rspec ./spec/integration/spec_helper.rb:77 # Common Table Expressions should
give correct results for recursive WITH
After adding the RECURSIVE statement to the WITH. Got these to start to work
other than this one.
"WITH RECURSIVE \"T\"(\"I\", \"PI\") AS (SELECT * FROM \"I1\" WHERE
(\"PARENT_ID\" IS NULL) UNION ALL SELECT \"I1\".\"ID\", \"I1\".\"PARENT_ID\"
FROM \"I1\" INNER JOIN \"T\" ON (\"T\".\"I\" = \"I1\".\"PARENT_ID\")) SELECT
\"I\" AS \"ID\", \"PI\" AS \"PARENT_ID\" FROM \"T\""
1) Common Table Expressions should give correct results for recursive WITH
Failure/Error: Unable to find matching line from backtrace
expected: [{:parent_id=>nil, :id=>1}, {:parent_id=>nil, :id=>2},
{:parent_id=>1, :id=>3}, {:parent_id=>1, :id=>4}, {:parent_id=>3, :id=>5},
{:parent_id=>5, :id=>6}]
got: [{:id=>1, :parent_id=>nil}, {:id=>2, :parent_id=>nil}, {:id=>4,
:parent_id=>1}, {:id=>3, :parent_id=>1}, {:id=>5, :parent_id=>3}, {:id=>6,
:parent_id=>5}] (using ==)
Diff:
@@ -1,7 +1,7 @@
-[{:parent_id=>nil, :id=>1},
- {:parent_id=>nil, :id=>2},
- {:parent_id=>1, :id=>3},
- {:parent_id=>1, :id=>4},
- {:parent_id=>3, :id=>5},
- {:parent_id=>5, :id=>6}]
+[{:id=>1, :parent_id=>nil},
+ {:id=>2, :parent_id=>nil},
+ {:id=>4, :parent_id=>1},
+ {:id=>3, :parent_id=>1},
+ {:id=>5, :parent_id=>3},
+ {:id=>6, :parent_id=>5}]
Looks like the hash is in the wrong order. I didn't think an array of hashes
comparison would result in this failure. I don't think I'm sorting them as a
fetch them.
Many thanks! Getting there slowly but surely.
Regards,
-GregD
----- Original Message -----
From: "Jeremy Evans" <[email protected]>
To: [email protected]
Sent: Sunday, August 18, 2013 4:39:28 PM
Subject: Re: SqlAnywhere adapter Simple dataset operations with nasty table
names should work correctly
On Saturday, August 17, 2013 7:24:24 PM UTC-7, GregD wrote:
Jeremy-
Thanks for all the help. I added to the cspecify for that one test. But, now
I'm having a really really bad thing happening when I run a lot of tests:
Sequel::DatabaseError:
Sequel::SqlAnywhere::SQLAnywhereException: Resource governor for 'prepared
statements' exceeded
This means that something is not being closed//cleaned-up properly. See this in
Java if a statement is not closed. Looking at my code I don't see where I am
not closing/freeing and comparing that to the AR code, I think I'm good. So, I
think this is maybe a problem with the ruby sqlanywhere native driver. I
updated the gist https://gist.github.com/gditrick/6240781 with the latest. From
the ruby sqlanywhere native driver, it says to do sqlany_free_stmt(rs) on the
result set statement. If you look at my code, I'm doing that after the yield on
both my execute and execute_dui. So, unless Sequel is doing something behind
the scenes, it has to be something with the sqlanywhere native driver. I may
have to ping the developer of it, but AR is doing it the in a similar way.
You need to put the sqlany_free_stmt(rs) calls in ensure blocks. Otherwise, if
there is an exception raised or an early exit (return/break/throw), those
aren't getting called.
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 http://groups.google.com/group/sequel-talk .
For more options, visit https://groups.google.com/groups/opt_out .
--
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 http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/groups/opt_out.
