<    April 2017    >
Su Mo Tu We Th Fr Sa  
 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  
01:24 GitHub21 joined
01:24 <GitHub21> [13sequel] 15janko-m opened pull request #1343: Improve documentation for window functions (06master...06improve-window-documentation) 02https://git.io/v9kwO
01:24 GitHub21 left
02:18 GitHub170 joined
02:18 <GitHub170> [13sequel] 15jeremyevans commented on issue #1343: Looks good, thanks for the patch! 02https://git.io/v9koV
02:18 GitHub170 left
02:19 GitHub100 joined
02:19 <GitHub100> [13sequel] 15jeremyevans pushed 1 new commit to 06master: 02https://git.io/v9kor
02:19 <GitHub100> 13sequel/06master 147379008 15Janko Marohnić: Improve documentation for window functions
02:19 GitHub100 left
02:19 GitHub56 joined
02:19 <GitHub56> [13sequel] 15jeremyevans closed pull request #1343: Improve documentation for window functions (06master...06improve-window-documentation) 02https://git.io/v9kwO
02:19 GitHub56 left
02:26 <adam12> jeremyevans: I'm looking to select two SUMs, using a model to setup my query. Is there a nice method to return them as an array?
02:27 <adam12> I'll try to rephrase if my quesiton isn't clear.
02:27 <jeremyevans> adam12: select_map{[sum(:col1).as(:s1), sum(:col2).as(:s2)]}
02:27 <adam12> heh
02:27 <adam12> I'm looking at that _exact_ section right now in rdoc. Just came to it
02:27 <adam12> Thanks.
02:30 <adam12> It comes back as an array in an array. flatten or is there another query I should chain on?
02:49 <adam12> nm. I went a different route.
05:56 cyclotron3k joined
05:57 <cyclotron3k> quick question, if I require sequel, with warnings on. I get this: "/var/lib/gems/2.3.0/gems/sequel-4.45.0/lib/sequel/model.rb:140: warning: instance variable @Model_cache not initialized"
05:58 <jeremyevans> cyclotron3k: Sequel is not designed to be free of instance variable initialization warnings
05:58 <cyclotron3k> Is that ok?
05:58 <cyclotron3k> ok
05:58 <jeremyevans> cyclotron3k: at least in ruby 2.4, you can filter warnings :)
05:58 <cyclotron3k> I nned to upgrade
05:58 <cyclotron3k> Thanks Jeremy
07:56 GitHub143 joined
07:56 <GitHub143> [13sequel] 15baelter opened issue #1344: Sequel.extension has on effect 02https://git.io/v9kAy
07:56 GitHub143 left
08:03 GitHub41 joined
08:03 <GitHub41> [13sequel] 15celsworth commented on issue #1344: I think this is working as intended. If you want to load the extension for all future database objects,... 02https://git.io/v9kxm
08:03 GitHub41 left
08:06 GitHub132 joined
08:06 <GitHub132> [13sequel] 15baelter commented on issue #1344: Oh, okey.... 02https://git.io/v9kxK
08:06 GitHub132 left
08:12 GitHub189 joined
08:12 <GitHub189> [13sequel] 15celsworth commented on issue #1344: Ah, see the [changelog](http://sequel.jeremyevans.net/rdoc/files/doc/release_notes/4_45_0_txt.html) which would explain it..... 02https://git.io/v9kpU
08:12 GitHub189 left
08:12 <Caesium> jeremyevans: perhaps that pg_hstore change is a bit major/breaking to be in a minor release?
08:13 <Caesium> I wonder how many people are (lazily/incorrectly) doing Sequel.extension with it
14:02 <Lyfe> jeremyevans: If you remove the add_* association funtions, is there a way to tell sequel to update it's association with new data without having to have it re-query that data from the database?
14:07 tercenya joined
14:35 GitHub2 joined
14:35 <GitHub2> [13sequel] 15jeremyevans closed issue #1344: Sequel.extension has no effect 02https://git.io/v9kAy
14:35 GitHub2 left
14:35 GitHub71 joined
14:35 <GitHub71> [13sequel] 15jeremyevans commented on issue #1344: This is currently the expected behavior. The fact that pg_hstore worked in previous instances if you didn't load the extension into the Database was a side effect of an implementation detail, not by design. 02https://git.io/v9Iyu
14:35 GitHub71 left
14:36 <jeremyevans> Caesium: No, I don't think it's major/breaking. If people weren't loading pg_hstore into the Database, there code was already broken. :)
14:36 <jeremyevans> Lyfe: obj.association(:reload=>true)
14:39 <Lyfe> jeremyevans: I was actually reading your email about removing the add_* associations in sequel 5, and realized that it would be a minor difficulty for me to go through my code and explicitly state which associations I want to have the 'non-read-only' methods for. So, nevermind.
14:41 <Lyfe> Since I can still use them on a case-by-case basis (eg, the ones I would need to maintain existing code), then I can support the change you're talking about.
14:42 <jeremyevans> Lyfe: OK. This will be easier when I actually deprecate it, because you'll get deprecation warnings every time you call a method that would no longer be defined
14:42 <jeremyevans> Lyfe: So as long as you have decent code coverage, nothing will break if you fix the deprecation warnings
14:42 <Lyfe> wait, you're deprecating the add_* functions? I thought it was simply being removed unless you provide the :read_only=>false parameter?
14:43 <jeremyevans> Lyfe: Correct, it is being removed unless :read_only=>false. However, there would be deprecation warnings if you called a method that would no longer be defined once that change was made
14:43 <Lyfe> Gotcha.
16:35 tercenya joined
18:03 tercenya joined
21:45 tercenya joined
22:11 aidalgol joined
22:54 GitHub191 joined
22:54 <GitHub191> [13sequel] 15jeremyevans pushed 12 new commits to 06master: 02https://git.io/v9tLP
22:54 <GitHub191> 13sequel/06master 147287931 15Jeremy Evans: Deprecate Database::{STRING_DEFAULT_RE,CURRENT_TIMESTAMP_RE}...
22:54 <GitHub191> 13sequel/06master 14696d483 15Jeremy Evans: Deprecate Sequel::Schema::Generator constant, use Sequel::Schema::CreateTableGenerator instead...
22:54 <GitHub191> 13sequel/06master 14ad2a87a 15Jeremy Evans: Add deprecation guard for set_overrides integration test
22:54 GitHub191 left
23:14 <* Caesium> is starting to get worried how hard upgrading ot Sequel 5 will be :p