01:50 <dbussink> yawniek: ah, yeah, i think i have it applied here locally, haven't pushed it yet though

02:19 <yawniek> ok, just wanted to know, if i can convice the others so that we use dm it would be handy to not need to have a extra gem

02:21 <yawniek> we cant upgrade bc our cms uses a table SQL and we only have binaries. really cool...

04:08 <dbussink> yawniek: could see if we could do a quick release, there are some other fixes in there that could be useful for people but i want to finish them first

04:59 <yawniek> no hurry for me

05:00 <yawniek> i just wanted to know if it every will be released. when is not that important

09:24 <github> dm-more: master snusnu * 5024951 (1 files in 1 dirs): [dm-timestamps] require 'dm-core' because we need it - http://bit.ly/dqdl1e

14:48 <dbussink> myabc: ping

15:09 <myabc> dbussink: pong

15:10 <dbussink> myabc: i was thinking about row_count in DO::Reader, to see whether we could perhaps make it optional

15:10 <dbussink> there were issue with supporting that in jruby right?

15:10 <myabc> dbussink: its not in our official API atm

15:11 <dbussink> yeah, i know, but got some questions about it

15:12 <myabc> dbussink: yep not all jdbc implementations will support it

15:12 <dbussink> myabc: well, not all is a lot better than none :)

15:12 <dbussink> myabc: do you know which ones will be problematic?

15:13 <myabc> dbussink: I think SQLite3 would be problematic

15:13 <myabc> dbussink: not sure about MySQL

15:13 <myabc> dbussink: PostgreSQL JDBC Impl. is pretty good + complete

15:13 <dbussink> myabc: well, frankly sqlite3 on jruby is problematic in general afaik

15:13 <myabc> http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html is what we'd use

15:14 <myabc> dbussink: sorry, scrollable ResultSets is what we'd use to implement this. I think pietia looked into this a while back too

15:14 <myabc> dbussink: v. true. its improved a little.. but is a not a v. complete JDBC implementation

15:16 <dbussink> myabc: well, i'd be willing to make sqlite3 on jruby divert for this

15:17 <myabc> dbussink: ok.. I'd actually be willing to fork /vendor sqlite3/work on sqlite3 upstream, if need be (at least later on, if there's demand)

15:18 <dbussink> myabc: well, for jruby there are also good alternatives with h2, hsqldb, etc.

15:18 <myabc> dbussink: yep..

15:18 <myabc> dbussink: just need to get the DM adapters written :)

15:28 <dbussink> myabc: hehe, yeah

15:29 <dbussink> myabc: but if you or pietia think it's doable, i probably want to add it back

15:29 <dbussink> it's easy for the c sqlite, mysql and postgres drivers

15:29 <myabc> dbussink: ok.. may I ask why?

15:29 <dbussink> myabc: well, people have been asking for getting it in

15:29 <myabc> dbussink: I do think its do-able for what is worth

15:29 <dbussink> and i'm open for it if it's doable

15:30 <myabc> dbussink: just last time around, there wasn't a strong use-case for it

15:30 <dbussink> myabc: yeah, true, but things might change :P

15:33 <myabc> dbussink: ok.. well go ahead and impement on the C side

15:33 <myabc> dbussink: and I'll try to keep up with you :)

15:34 <dbussink> but i'm heading off, ttyl!

15:43 <myabc> dbussink: ok.. np..