<    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 25  
26 27 28 29 30 31
00:16 haennar joined
00:19 <scratchcat> I've also come to notice that the 2nd transaction (although it sends the command to acquire the lock after the first transaction) commits first (successfully) and the first transaction aborts (is there a mechanism that chooses commit-first rather than acquire-lock-first)?
00:44 <jeremyevans> scratchcat: If you could post some example code, I could take a look.
00:56 scratchcat joined
00:58 <scratchcat> it 'final test' do
00:58 <scratchcat> require 'fork_break'
00:58 <scratchcat> include ForkBreak::Breakpoints
00:58 <scratchcat> journals.create!( id: 'j2' )
00:58 <scratchcat> process1 = ForkBreak::Process.new do | breakpoints |
00:58 <scratchcat> Models::Sequel::Journal.db.transaction do
00:58 <scratchcat> Models::Sequel::Journal.for_update.first( external_id: 'j2' )
00:58 <scratchcat> breakpoints << :locked_row
00:58 <scratchcat> end
00:58 <scratchcat> end # ends up aborting
00:58 <scratchcat> process1.run_until( :locked_row ).wait
00:58 <scratchcat> require 'byebug'; byebug
00:58 <scratchcat> Models::Sequel::Journal.db.transaction do
00:58 <scratchcat> Models::Sequel::Journal.for_update.first( external_id: 'j2' ) # does not raise error
00:58 <scratchcat> end # ends up being committed
00:58 <scratchcat> end
00:58 <scratchcat> The second version: used this : process1 = ForkBreak::Process.new do | breakpoints |
00:58 <scratchcat> Scratch::Abacus::Core::Backends::Postgres::Models::Sequel::Journal.db.transaction do
00:58 <scratchcat> journal1 = Scratch::Abacus::Core::Backends::Postgres::Models::Sequel::Journal.db.fetch(
00:58 <scratchcat> "select * from journals where external_id='j1' FOR UPDATE NOWAIT"
00:58 <scratchcat> ).first
00:58 <scratchcat> require 'byebug'; byebug
00:58 <scratchcat> breakpoints << :locked_row
00:58 <scratchcat> require 'byebug'; byebug
00:58 <scratchcat> end
00:58 <scratchcat> end
00:59 <jeremyevans> scratchcat: In general you should use a link to a code paste site like pastebin, instead of posting the code inline
00:59 <scratchcat> oops, thanks I'll do that
01:00 <jeremyevans> scratchcat: I'm not familiar with fork_break, is it something equivalent to using fork
01:01 <scratchcat> http://pastebin.com/KR0NvDU8
01:01 <scratchcat> fork_break allows me to create processes where I can run code up till certain "breakpoints" so I can control concurrency tests
01:01 <scratchcat> (it spins off processess)
01:01 <jeremyevans> scratchcat: Are you calling DB.disconnect before forking?
01:02 <scratchcat> I can also provide the log which indicates the 2 transactions are started concurrently
01:02 <scratchcat> no
01:02 <jeremyevans> scratchcat: Otherwise you are sharing the database connection between the processes
01:02 <scratchcat> yes I am
01:02 <jeremyevans> scratchcat: You don't want to do that, you should always disconnect connections before forking
01:02 <scratchcat> I see, why is that?
01:03 <scratchcat> Is that the issue?
01:03 <scratchcat> so i need to disconnect and reconnect in the separate process?
01:03 <jeremyevans> scratchcat: reconnection will happen automatically
01:03 <jeremyevans> scratchcat: disconnecting before fork is enough
01:04 <scratchcat> Both the parent process and the forked process will then reconnect automatically?
01:04 <jeremyevans> scratchcat: yep
01:05 <scratchcat> that's it!! Thanks so much
01:06 <scratchcat> Is there somewhere to know these good-to-knows for sequel? (e.g. where could I have known to disconnect before forking?)
01:07 <jeremyevans> scratchcat: It's mentioned in http://sequel.jeremyevans.net/rdoc/files/doc/code_order_rdoc.html
01:07 <jeremyevans> scratchcat: It's also mentioned in the PostgreSQL documentation
01:08 <scratchcat> Great, thanks!
01:08 <jeremyevans> scratchcat: This isn't PostgreSQL specific, almost all database drivers do not support sharing connection sockets between processes
01:09 <scratchcat> Kk, great to know thanks
01:09 <scratchcat> I'm a little new to these things, so thanks for answering my questions so quickly!
01:11 <jeremyevans> scratchcat: no problems, that's what we are here for :)
01:13 <scratchcat> :)
01:35 <lopex> jeremyevans: hi, were ther emany issues wrt http://stackoverflow.com/questions/6345635/how-to-select-several-hardcoded-sql-rows ?
01:37 <lopex> I have curious case for sqlite
01:37 <lopex> "SELECT * FROM (SELECT `group`.`id`, `group`.`name` FROM `group` UNION ALL SELECT 'foo' AS '', 'bar' AS '') ORDER BY `name`"
01:37 <lopex> that works
01:37 <lopex> whereas "SELECT * FROM (SELECT `group`.`id`, `group`.`name` FROM `group` UNION ALL SELECT 'foo' AS '', 'bar' AS '') ORDER BY `group`.`name`"
01:37 <lopex> doesn
01:38 <lopex> the only diff is fully qualified `group`.`name` in order
01:39 <lopex> that's not a sequel issue
01:40 <lopex> but I wonder if it can be targeted via common apis
02:15 mwlang joined
03:44 scratchcat joined
04:48 <jeremyevans> lopex: the second query is wrong, as group is not a valid qualifier in that order clause. You shold be aliasing the subquery and qualifying to the subquery alias if you want to use a qualified identifier there
04:49 <jeremyevans> lopex: Sequel always aliases subqueries, but in general it is up to the user to qualify things, unless you use Dataset#qualify
06:14 scratchcat1 joined
06:34 ta_ joined
06:53 glennpratt joined
08:01 ta_ joined
08:16 scratchcat joined
09:29 ta_ joined
10:00 haennar joined
10:33 ta_ joined
11:05 mwlang joined
14:17 d762b440__ joined
14:31 mwlang joined
15:49 <lopex> jeremyevans: oh, so like this: ? db[:test].select(:name, :id).union(db.select('foo'.as(:name), '0'.as(:id)), all: true).order(:name.qualify(:t1))
15:49 <lopex> how do I control the DATASET_ALIAS_BASE_NAME ?
19:23 <jeremyevans> lopex: You shouldn't need to, just pass in the :alias option to union
19:24 <lopex> jeremyevans: yeah, did that, thx
20:37 scratchcat joined
22:36 scratchcat joined
23:03 d762b440__ joined
23:27 filterfish joined