<    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:34 mwlang joined
00:54 AYGHOR joined
00:56 <bougyman> AYGHOR: is it postgresql?
01:00 <AYGHOR> does anybody know how to DELETE on a JOIN?
01:00 <AYGHOR> Task.association_join(:account).where(account: {something: 1}).delete
01:00 <AYGHOR> something liek this
01:00 <AYGHOR> it gives Sequel::Error: Need multiple FROM tables if updating/deleting a dataset with JOINs
01:01 <AYGHOR> i want to delete tasks based on some associated account value
01:06 AYGHOR joined
01:06 <AYGHOR> dropped =o(
01:18 glennpratt joined
01:37 glennpratt joined
01:48 glennpratt joined
02:09 glennpratt joined
02:23 glennpratt joined
02:26 glennpratt joined
02:31 filterfish joined
02:32 glennpratt joined
02:33 glennpratt joined
03:02 jeremyevans joined
03:18 glennpratt joined
04:13 glennpratt joined
05:07 glennpratt joined
06:01 glennpratt joined
06:55 glennpratt joined
07:17 filterfish joined
07:49 glennpratt joined
08:28 <mmun> is it possible to eagerload an association multiples times (maybe by aliasing them to a "virtual" association, if you get what i mean)
08:30 <mmun> it would make implementing http://graphql.org/learn/queries/#aliases easier
08:59 <mmun> a bit more context: https://gist.github.com/mmun/3c72986a48fb30ba4d555073b83b5f6c
08:59 <jeremyevans> mmun: Not currently. But I don't see a need. Can't you just eager load, then rename the associations?: Model.all{|o| o.associations[:new_name] = o.associations.delete(:old_name)}
09:04 <jeremyevans> mmun: you could probably do that using the tacital_eager_loading plugin, and eager loading each alias one at a time, then renaming after each. You could also do it with a custom eager loader
09:05 <jeremyevans> mmun: But I think you'll find that Sequel::Model was not designed around the needs of graphql, and that's not really a goal.
09:05 <mmun> jeremyevans: it's the best option i've seen :)
09:05 <mmun> thanks
09:05 <jeremyevans> mmun: Even in your example, you'd really want two separate associations, one that ordered comments by best (score descending), and one by worst (score ascending)
09:05 <mmun> yeah
09:06 <jeremyevans> mmun: You could always eager load all comments for each post, then use array slicing to get the best and worst
09:06 <mmun> i'm a bit worried about malicious users naming their alises things like `save` or whatever
09:06 <mmun> but ignoring that...
09:07 <jeremyevans> mmun: associations are keyed by symbol in the associations hash, so you could use :associations[:save] to get them
09:08 <jeremyevans> mmun: In any case, graphql is nice from a user perspective, but I wouldn't want to support it on the back end, way to easy to be malicious in terms of denial of service
09:08 <jeremyevans> mmun: anyway, it's late here, time for bed
09:08 <mmun> Post.where(ids: [1,2,3]).eager_as(:top_five_comments => proc { |ds| ds.comments.reverse(:score).limit(6) })
09:08 <mmun> eager_As being my own invention ^
09:09 <jeremyevans> mmun: eager loading with limits doesn't work that way, just so you know :)
09:09 <jeremyevans> mmun: ignoring the aliasing issues
09:09 <mmun> ah ok
09:09 <mmun> well thanks and sorry to keep you
09:09 <jeremyevans> mmun: http://code.jeremyevans.net/presentations/rubyc2014-1/index.html#1 if you want the details on eager loading limited associations
09:37 glennpratt joined
10:31 glennpratt joined
11:26 glennpratt joined
12:20 glennpratt joined
13:14 glennpratt joined
14:08 glennpratt joined
15:20 <adam12> Wow that's an advanced talk
15:56 glennpratt joined
17:44 glennpratt joined
17:45 bougyman joined
17:45 bougyman joined
18:36 <mmun> that makes a lot of sense in hindsight
18:38 glennpratt joined
18:39 <mmun> i'd probably have to write an ORM from scratch to have enough knowledge to understand why my naive version couldn't/shouldn't be transformed to thing i was expecting :P
19:32 glennpratt joined
20:27 glennpratt joined
21:20 glennpratt joined
22:14 glennpratt joined