On Oct 3, 2013, at 9:37 PM, Jeremy Evans <[email protected]> wrote:
> On Thursday, October 3, 2013 6:07:02 PM UTC-7, GregD wrote: > Jeremy- > > I tried: > > 1) adding getting the meta data of column_type_name to the process_result_set > method in the jdbc adapter: > 2) changed the method process_result_set_convert to pass the column_type_name > to the convert_type_proc > 3) then in my sqlanywhere specific jdbc adapter I override the > convert_type_proc and that will call super. > > This worked for all the jdbc data types via the default super and allowed me > to convert "smallint" to a boolean. > > The gist is updated with this code: https://gist.github.com/gditrick/6240781 > > Do you see a problem with this approach? I know this makes smallint a > boolean no matter if the user wants a smallint. But the native one will be > doing that anyway. Shame SqlAnywhere does not a boolean type. In our java > code and stored procs, we use either a smallint or a char of 'Y' or 'N'. I > could switch this to the char approach, but looking at the other adapters, I > like using the smallint. Thoughts? > > With this change and the alter table changes: The jdbc sqlanywhere > integration test results are 539 tests, 0 failing, only 2 pending. > > Personally, I'm fine with the jdbc/sqlanywhere adapter not emulating > booleans, and just marking the related boolean tests as pending. As the > underlying jdbc driver doesn't automatically convert smallint to boolean, I > think at the very least we would want to make the behavior optional so that > the user can choose whether they want to do the conversion. Otherwise, > Sequel would be basically unusable for users that have smallint columns that > aren't used to store booleans. Okay, I was trying to get the behavior of the jdbc 1 to be like how I set up the native 1. But, I can see your point and almost feel like I should make the native one do that instead. And looking at others, I thought this was the approach. Thoughts? > > It's great that you got the test suite passing cleanly. I'd definitely like > to get this merged before 4.4.0. Any change you could provide a unified/git > diff or a git repository I can pull from? I'm new to this. So, what is your preference? If I do a git repo, do I fork it first. I did a clone of you repo, so I've been getting the updates regularly with a pull. -GregD -- 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.
