<    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:06 filterfish joined
00:24 mwlang joined
00:41 glennpratt joined
00:48 <mmun> Is there a way to select certain fields on an eager loaded relationship on a per-invocation basis? (as opposed to using the `select` option on the entire association)
00:51 <mmun> follow up question: can you do this with the tactical eager loading plugin?
01:12 anazar_ joined
01:18 <anazar_> @jeremyevans -- we're using sequel with graphql and the ideal situation is to return objects that map to graphql types. Our concern is when we have to query across a bunch of users with associations... is there a way to do that and work with the objects that isn't very resource intensive? Currently we're just using datasets to get a hash of fields. The
01:18 <anazar_> other issue is we don't actually need all fields but only the fields requested in the graphql query so an object could have a lot of unecessary data.
01:19 <jeremyevans> mmun: Yes. You can use an eager load callback for per-invocation eager load customization, and I believe it is possible to use this with tactical_eager_loading by specifying an :eager option to the association method with the eager load callback
01:21 <jeremyevans> anazar_: Using datasets should be fine. You can use models and eager loading, but while simpler it is unlikely to be faster
01:28 <mmun> thanks I'll keep experimenting.
01:28 <mmun> I'm having some fun writing a Sequel adapter for graphql-ruby
01:32 <mmun> my interpretation of your response is `Albums.eager(:artist => proc{|ds| ds.select(:name)})` for the first part and `album.artist(:eager => proc{|ds| ds.select(:name)})` for the second part. does that seem rightish?
01:36 <mmun> oh... nevermind. I think you were referring to the :callback described in the TEL docs
01:37 <mmun> ah, those are the same thing.
01:59 filterfish joined
02:30 mwlang joined
02:37 GitHub0 joined
02:37 <GitHub0> [13sequel] 15pabloh opened issue #1316: `Database#indexes` method fails for qualified tables 02https://git.io/vyBbC
02:37 GitHub0 left
02:53 GitHub43 joined
02:53 <GitHub43> [13sequel] 15jeremyevans commented on issue #1316: Looks like Database#indexes doesn't handle qualified tables on mysql. This should be fairly easy to fix, I'll work on a patch tomorrow. 02https://git.io/vyBNm
02:53 GitHub43 left
02:54 <jeremyevans> mmun: that seems right
03:15 GitHub20 joined
03:15 <GitHub20> [13sequel] 15pabloh commented on issue #1316: That was fast... :open_mouth: ... 02https://git.io/vyBAo
03:15 GitHub20 left
03:34 scratchcat joined
03:34 scratchcat left
03:59 mwlang joined
04:22 glennpratt joined
07:24 glennpratt joined
08:01 aidalgol joined
08:03 glennpratt joined
08:35 ta_ joined
09:25 Bish joined
09:26 GitHub66 joined
09:26 <GitHub66> [13sequel] 15fnordfish opened issue #1317: Irretating error message when using non-existing Model plugin 02https://git.io/vyRcw
09:26 GitHub66 left
14:03 Bish joined
15:13 ta_ joined
15:52 glennpratt joined
16:23 mwlang joined
16:24 ta_ joined
16:41 GitHub150 joined
16:41 <GitHub150> [13sequel] 15jeremyevans commented on issue #1317: The root cause of the problem appears to be you are not setting the database connection before creating the model classes. See http://sequel.jeremyevans.net/rdoc/files/doc/code_order_rdoc.html. I'm not sure why things would work if the `my_plugin` plugin was available.... 02https://git.io/vy0CW
16:41 GitHub150 left
16:41 GitHub119 joined
16:41 <GitHub119> [13sequel] 15jeremyevans closed issue #1317: Irretating error message when using non-existing Model plugin 02https://git.io/vyRcw
16:41 GitHub119 left
16:48 mwlang joined
18:17 GitHub84 joined
18:17 <GitHub84> [13sequel] 15jeremyevans pushed 1 new commit to 06master: 02https://git.io/vy0i8
18:17 <GitHub84> 13sequel/06master 143edb81c 15Jeremy Evans: Make Database#indexes on MySQL handle qualified identifiers (Fixes #1316)
18:17 GitHub84 left
18:17 GitHub38 joined
18:17 <GitHub38> [13sequel] 15jeremyevans closed issue #1316: `Database#indexes` method fails for qualified tables 02https://git.io/vyBbC
18:17 GitHub38 left
18:24 GitHub128 joined
18:24 <GitHub128> [13sequel] 15fnordfish commented on issue #1317: Will do (I'm pretty sure my db setup runs before loading models). Any preferences? As small as possible, or smallest padrinorb sample (to be more close to my real project)? 02https://git.io/vy0P2
18:24 GitHub128 left
18:26 GitHub153 joined
18:26 <GitHub153> [13sequel] 15jeremyevans commented on issue #1317: As small as possible to show the problem, with just using Sequel, without using padrinorb. From the code you posted, I assumed you were loading the models in the `# ...` part, and the database connections was after that. 02https://git.io/vy0PF
18:26 GitHub153 left
19:13 GitHub41 joined
19:13 <GitHub41> [13sequel] 15chanks opened issue #1318: Spurious "no transaction in progress" warnings due to deferrable constraints in Postgres 02https://git.io/vy0Hd
19:13 GitHub41 left
19:20 banditron joined
19:24 aidalgol joined
19:30 GitHub154 joined
19:30 <GitHub154> [13sequel] 15jeremyevans closed issue #1318: Spurious "no transaction in progress" warnings due to deferrable constraints in Postgres 02https://git.io/vy0Hd
19:30 GitHub154 left
19:30 GitHub47 joined
19:30 <GitHub47> [13sequel] 15jeremyevans commented on issue #1318: Anytime `COMMIT` fails, Sequel will attempt to issue `ROLLBACK` to be sure that the transaction is closed. This is the default behavior for all databases (https://github.com/jeremyevans/sequel/blob/master/lib/sequel/database/transactions.rb#L225-L236). ... 02https://git.io/vy05K
19:30 GitHub47 left
19:36 GitHub178 joined
19:36 <GitHub178> [13sequel] 15jeremyevans commented on issue #1318: Adding more detail: skipping the `ROLLBACK` if `conn.transaction_status == 0` will probably work, but you can only do it in the postgres adapter (not in the shared postgres adapter), and then only when the pg driver is used (`Sequel::Postgres::USES_PG == true`). 02https://git.io/vy0dN
19:36 GitHub178 left
19:45 mwlang joined
21:07 mwlang joined
22:06 glennpratt joined
22:06 glennpratt joined
22:34 GitHub176 joined
22:34 <GitHub176> [13sequel] 15KJTsanaktsidis opened issue #1319: MySQL driver acquires a pool connection for each placeholder that needs escaping 02https://git.io/vyElv
22:34 GitHub176 left
22:45 GitHub131 joined
22:45 <GitHub131> [13sequel] 15jeremyevans closed issue #1319: MySQL driver acquires a pool connection for each placeholder that needs escaping 02https://git.io/vyElv
22:45 GitHub131 left
22:45 GitHub138 joined
22:45 <GitHub138> [13sequel] 15jeremyevans commented on issue #1319: This is only necessary to escape strings, and many queries do not escape strings at all, so checking out a connection for every query seems unnecessary. There are corner cases like the ones you are hitting, but those are simple to work around in your code by using `synchronize` manually.... 02https://git.io/vyE8S
22:45 GitHub138 left
22:52 GitHub40 joined
22:52 <GitHub40> [13sequel] 15KJTsanaktsidis commented on issue #1319: Thanks for the prompt response and the pointers for how to implement this correctly inside Sequel.... 02https://git.io/vyE4a
22:52 GitHub40 left
23:10 GitHub34 joined
23:10 <GitHub34> [13sequel] 15jeremyevans commented on issue #1319: If you have an application doing anything that modifies per-connection state and returns the connection to the pool without resetting the state, you have a potential issue. Trying to prevent issues that modifying per-connection state causes just in this particular case doesn't make much sense since this is a general issue.... 02https://git.io/vyE0w
23:10 GitHub34 left
23:13 GitHub192 joined
23:13 <GitHub192> [13sequel] 15KJTsanaktsidis commented on issue #1319: Right - that makes good sense. I hadn't considered that `.each` and `all` execute a user-provided block. I'll try and find some time to write a dataset extension and submit a PR. 02https://git.io/vyEEJ
23:13 GitHub192 left