<    June 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
00:04 <plujon> jeremyevans: http://ix.io/wEG # still fails
00:04 <plujon> Should a bug be filed?
00:06 <plujon> I'm puzzled, though. class_table_inheritance_spec.rb looks like it tests for this (see Ceo.create). Maybe I'm doing something wrong.
00:11 glennpratt joined
00:14 <plujon> $ rspec # 0 examples, 0 failures, 59 errors occurred outside of examples, . . . undefined method `deprecated' . . .
00:15 <jeremyevans> plujon: This does look like a bug. Tests use minitest, not rspect
00:15 <plujon> Ah, good to know; I'm pathetically unversed in both minitest and rspec.
00:19 glennpratt joined
00:20 <jeremyevans> plujon: The issue appears to be caused when using class table inheritance when you could use single table inheritance
00:21 <jeremyevans> plujon: More specifically, when the primary table is used for a subclass without the subclass using for a different table, and when the :alias option is used
00:22 <jeremyevans> plujon: So it is a bug. Not technically a regression since it only shows up when using a new option, so it doesn't break existing code.
00:23 <jeremyevans> plujon: This is kind of a special case though, as the previous code is deprecated and you have to move to using the new option to avoid the deprecation warning
00:23 <plujon> jeremyevans: What about http://ix.io/wEK ?
00:24 <plujon> I think that is using class table inheritance, but the same issue seems to exist.
00:24 <plujon> I assume the new option of which you speak is "alias".
00:25 <jeremyevans> plujon: nope, Staff assumes staffs table, not staff, so same issue. With staffs table, works corretly
00:25 <jeremyevans> plujon: correct, the :alias option
00:25 <jeremyevans> plujon: This shouldn't be a difficult fix, give me a few minutes
00:26 <plujon> Ah, staffs.
00:28 <jeremyevans> plujon: https://pastebin.com/raw/gbgxgKGR
00:28 <plujon> FWIW, I just got in the habit of using class_table_inheritance, and didn't even think about using single_table_inheritance even when no subclass (yet) had its own unique column.
00:28 glennpratt joined
00:29 <plujon> jeremyevans: Cool, thanks. I'll switch to STI for this particular model for now, but I assume the fix will trickle into production in awhile.
00:29 ben__ joined
00:29 <jeremyevans> plujon: FWIW, I never use model inheritance in any of my apps. It's a bit too magical for me, I generally just use a single class with conditionals in the case where behavior would differ as I find that easier to understand.
00:30 <jeremyevans> plujon: Yes, this fix will definitely make the next release
00:30 <plujon> Cool, thanks again.
00:31 <plujon> BTW: Recently switched to roda / rodauth; loving it.
00:33 <plujon> I think what I like most is that I can stop deciding things and instead simply "trust Jeremy".
00:35 <jeremyevans> plujon: That's great :)
00:42 <* plujon> ponders his frequent use of inheritance
00:47 <jeremyevans> plujon: I should add that I don't often work on things that would naturally benefit from inheritance, and there is only a few places in my apps where I would have to make such a choice
00:48 <onewheelskyward> Every time I've considered it, I engineered a simpler solution.
00:48 <onewheelskyward> haha I've found much the same plujon
00:48 <onewheelskyward> re: trust jeremy
00:48 <jeremyevans> plujon: If you have a lot of places where inheritance would be helpful, using inheritance can be a good choice, it's not necessarily a bad decision in all cases
00:54 ben__ joined
00:56 GitHub96 joined
00:56 <GitHub96> [13sequel] 15jeremyevans pushed 1 new commit to 06master: 02https://git.io/vHizp
00:56 <GitHub96> 13sequel/06master 14940bfc4 15Jeremy Evans: Fix incorrect SQL used for inserting into a CTI subclass sharing the primary table when using the :alias option...
00:56 GitHub96 left
00:57 <plujon> I might even use STI even when there is *no* difference in behavior between the subclasses, just so I can use Cook[] and Staff[] instead of Staff.cooks.
00:58 <plujon> Of course, usually, I think that in the future the subclasses will have class-specific behavior.
00:59 <plujon> Thanks again. o/
01:30 glennpratt joined
01:40 <adam12> In Jeremy We Trust
04:52 GitHub18 joined
04:52 <GitHub18> [13sequel] 15jeremyevans commented on issue #1375: The `to_hash` method isn't specific to ids/primary keys, and the class used is Hash and not Map, so method names with `map` or `id` don't really fit. `to_h` is a possible method name, and kind of makes sense, but `Enumerable#to_h` is already defined in ruby 2.4 and operates differently. ... 02https://git.io/vHiMc
04:52 GitHub18 left
04:59 GitHub141 joined
04:59 <GitHub141> [13sequel] 15pyromaniac commented on issue #1375: `as_hash` sounds good enough as for me. 02https://git.io/vHiMV
04:59 GitHub141 left
05:30 glennpratt joined
06:03 glennpratt joined
06:35 glennpratt joined
06:54 glennpratt joined
06:56 glennpratt joined
12:23 bendit joined
12:31 <bendit> With modern versions of sequel, I get undefined method `like' for :descrip:Symbol (NoMethodError)
12:31 <bendit> If I try to use DB[:whatever].filter(:column.like('foo'))
12:31 <bendit> It works in old versions
13:19 dreinull left
13:25 <Freaky> bendit: http://sequel.jeremyevans.net/rdoc/files/doc/core_extensions_rdoc.html
13:26 <Freaky> load the extension or switch to Sequel.like(:column, 'foo')
13:28 <bendit> Thank you!
13:30 ben__ joined
13:33 GitHub9 joined
13:33 <GitHub9> [13sequel] 15jeremyevans pushed 1 new commit to 06master: 02https://git.io/vHPEC
13:33 <GitHub9> 13sequel/06master 149c4af8d 15Jeremy Evans: Make pg_hstore extension reset hstore conversion proc when running Database#reset_conversion_procs...
13:33 GitHub9 left
18:35 ben__ joined
20:56 tercenya joined
21:10 ben__ joined
21:19 tercenya joined
21:44 plujon joined
23:36 poloych joined
23:36 poloych joined