<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 _2_5  
26 27 28 29 30 31
00:05 filterfish joined
00:32 filterfish joined
01:27 glennpratt joined
02:21 glennpratt joined
04:08 glennpratt joined
04:45 glennpratt joined
05:00 glennpratt joined
05:40 glennpratt joined
06:44 filterfish joined
06:50 aidalgol joined
06:53 filterfish joined
06:53 GitHub123 joined
06:53 <GitHub123> [13sequel] 15tmtm opened issue #1322: When timeout occurs in Sequel::Database#transaction, the transaction is committed. 02https://git.io/vy6qL
06:53 GitHub123 left
06:53 filterfish joined
06:56 filterfish joined
07:01 filterfish joined
07:02 filterfish joined
07:11 filterfish joined
07:28 glennpratt joined
07:57 ta_ joined
08:23 glennpratt joined
09:17 glennpratt joined
09:24 GitHub27 joined
09:24 <GitHub27> [13sequel] 15janko-m commented on issue #1322: @tmtm There actually is nothing that the Sequel library can do to work around this, and that's the major flaw of the Timeout standard library. You see, `Timeout.timeout` spawns a new thread that starts executing whatever is in the block, but once the N seconds have run out, it calls `Thread#kill` on that thread. The limitation of `Thread#kill` is that it won't call any `ensure` blocks, it will just termi
09:24 GitHub27 left
09:24 GitHub119 joined
09:24 <GitHub119> [13sequel] 15janko-m commented on issue #1322: @tmtm There actually is nothing that the Sequel library can do to work around this, and that's the major flaw of the Timeout standard library. You see, `Timeout.timeout` spawns a new thread that starts executing whatever is in the block, but once the N seconds have run out, it calls `Thread#kill` on that thread. The limitation of `Thread#kill` is that it won't call any `ensure` blocks, it will just ter
09:24 GitHub119 left
09:25 GitHub149 joined
09:25 <GitHub149> [13sequel] 15janko-m commented on issue #1322: @tmtm There actually is nothing that the Sequel library can do to work around this, and that's the major flaw of the Timeout standard library. You see, `Timeout.timeout` spawns a new thread that starts executing whatever is in the block, but once the N seconds have run out, it calls `Thread#kill` on that thread. The limitation of `Thread#kill` is that it won't call any `ensure` blocks declared by `Sequ
09:25 GitHub149 left
09:25 GitHub79 joined
09:25 <GitHub79> [13sequel] 15janko-m commented on issue #1322: @tmtm There actually is nothing that the Sequel library can do to work around this, and that's the major flaw of the Timeout standard library. You see, `Timeout.timeout` spawns a new thread that starts executing whatever is in the block, but once the N seconds have run out, it calls `Thread#kill` on that thread. The limitation of `Thread#kill` is that it won't call any `ensure` blocks declared by `Sequel
09:25 GitHub79 left
10:11 glennpratt joined
11:06 glennpratt joined
11:06 filterfish joined
12:00 glennpratt joined
12:36 filterfish joined
12:54 glennpratt joined
13:58 tercenya joined
14:41 glennpratt joined
14:45 ta_ joined
14:48 GitHub118 joined
14:48 <GitHub118> [13sequel] 15jeremyevans commented on issue #1322: I agree with @janko-m that this is a bug in Timeout and not in Sequel. It would be nice to handle Timeout since it is in the standard library, but I don't know of a way to examine the current throw value. If Timeout used a static catch value, we could catch and rethrow to handle correctly. Unfortunately, Timeout uses a separate Timeout::Error instance for each throw, without that information, I
14:48 GitHub118 left
14:48 GitHub179 joined
14:48 <GitHub179> [13sequel] 15jeremyevans closed issue #1322: When timeout occurs in Sequel::Database#transaction, the transaction is committed. 02https://git.io/vy6qL
14:48 GitHub179 left
14:53 glennpratt joined
15:49 GitHub128 joined
15:49 <GitHub128> [13sequel] 15jeremyevans pushed 1 new commit to 06master: 02https://git.io/vyiqn
15:49 <GitHub128> 13sequel/06master 14eccb83b 15Jeremy Evans: Make ORDER BY come after UNION/INTERSECT/EXCEPT on Microsoft SQL Server and SQLAnywhere
15:49 GitHub128 left
20:35 glennpratt joined
21:30 ta_ joined
21:38 AYGHOR joined
21:38 <AYGHOR> EHLO
21:38 <AYGHOR> does anybody know how to filter using a date range in a pretty way?
21:39 <jeremyevans> AYGHOR: where(:column=>date_range)
21:39 <AYGHOR> asd
21:39 <jeremyevans> AYGHOR: assuming by date range you mean something like Date.new(2010,1,1)..Date.new(2015,2,3)
21:39 <AYGHOR> asd
21:39 <AYGHOR> yea
21:39 <AYGHOR> ok
21:39 <AYGHOR> now wat if i need to get only stuff after a certain date
21:40 <AYGHOR> liek infinite right bound
21:40 <AYGHOR> DateTime::Infinity.new didnt work
21:40 <jeremyevans> AYGHOR: ruby doesn't support infinite bounds
21:40 <AYGHOR> do i have to plug in a bunch of ifs?
21:40 <jeremyevans> AYGHOR: you should just use >= and <= manually in that case
21:40 <AYGHOR> i can do (DateTime.today..DateTime::Infinity.new)
21:41 <AYGHOR> oops
21:41 <AYGHOR> DateTime.now..DateTime::Infinity.new
21:41 <AYGHOR> it works correctly
21:41 <AYGHOR> it also works on activerecord
21:42 <AYGHOR> if you feed a Infinity, it will just drop teh right bound on teh sql
21:42 glennpratt joined
21:43 <AYGHOR> do plugging a bunch of ifs is teh way to go with sequel?
21:45 <jeremyevans> AYGHOR: probably. We don't have special handling for DateTime::Infinity values
21:45 <AYGHOR> would you accept a patch?
21:46 <AYGHOR> liek checking for .infinite?
21:47 <jeremyevans> AYGHOR: I don't think checking for infinite? would work, since the object may not respond to it. I suppose respond_to?(:infinite?) && infinite? may work, but the logic is not that simple
21:48 <jeremyevans> AYGHOR: for example: Date::Infinity.new..Date::Infinity.new
21:48 <jeremyevans> AYGHOR: Also, some databases may have infinity values, so leaving the condition off may break things
21:49 <AYGHOR> hmm
21:49 <jeremyevans> AYGHOR: This type of behavior is probably database dependent. You would need a comprehensive test suite and test it on about 10 databases to make sure they all handled things correctly.
21:50 <AYGHOR> hmm
21:51 <AYGHOR> ok i will live with teh ifs for now
21:51 <AYGHOR> ty <3
21:55 <jeremyevans> AYGHOR: class Date::Infinity; def sql_literal(ds) "'#{'-' if Date.today > self}infinity'"; end end
21:55 <jeremyevans> AYGHOR: That may work on PostgreSQL (which has the concept of infinite dates)
21:56 <AYGHOR> hm
21:56 <AYGHOR> nice
21:57 <AYGHOR> but this is kinda magic
21:57 <AYGHOR> id rather avoid
21:57 <AYGHOR> =O3
21:57 <AYGHOR> but ty!
21:57 <AYGHOR> perhaps i will fall for it
21:58 <AYGHOR> sometimes magic is more readable
21:58 <AYGHOR> i use pg anyway
22:52 filterfish joined
22:56 <AYGHOR> EHLO once moar
22:57 <AYGHOR> does anybody know how to select stuff form teh db as hashes?
22:58 <AYGHOR> i mean, instead of model instances
22:58 <AYGHOR> liek DB[:tasks].all gives array of hashes
22:58 <AYGHOR> but Task.dataset.all gives array of Task
22:59 <AYGHOR> ops
22:59 <AYGHOR> i want results liek DB[:tasks].select(:prop).all
23:00 <AYGHOR> but from a previously filtered dataset: Task.where(...).dataset.select(:prop).all
23:00 <AYGHOR> is this possible?
23:02 <AYGHOR> i just managed to map(&:to_hash) and it is enough, but is there a better way/
23:03 <jeremyevans> AYGHOR: the Dataset#naked method exists for this
23:05 <AYGHOR> nice!