On Thursday, October 3, 2013 6:51:29 PM UTC-7, GregD wrote: > > On Oct 3, 2013, at 9:37 PM, Jeremy Evans <[email protected]<javascript:>> > 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? >
I don't have strong feelings either way. There's probably not going to be many users of it, so as long as the tests pass, I don't think we need to worry about now. We can always make modifications later if necessary. > > > 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. > If you have a GitHub account, just pushing your branch up to your fork on GitHub should be enough. Alternative, hosting your git repo anywhere I can access it should be fine. Worse cast scenario, providing the output of git diff against my master branch should be enough. I still need to get a local VM with sqlanywhere setup. I filled out the online form on Sybase's website, but they never sent a key for me to download the developer version. 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.
