<     May 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 _2_9 30 31
02:00 joast joined
05:47 GitHub168 joined
05:47 <GitHub168> [13sequel] 15perlun commented on issue #1357: Thinking about this a bit further: @jeremyevans, would you be willing to accept a patch that lets the `column` DSL method accept this syntax in addition to the existing one?... 02https://git.io/v954z
05:47 GitHub168 left
06:20 glennpratt joined
06:29 GitHub3 joined
06:29 <GitHub3> [13sequel] 15perlun opened pull request #1358: Added test for incorrect error logging in `table_exists?` (06master...06fix/dont-log-errors-in-table-exists) 02https://git.io/v95B5
06:29 GitHub3 left
08:07 GitHub190 joined
08:07 <GitHub190> [13sequel] 15perlun opened pull request #1359: Added note about the sequel-jdbc-as400 gem (06master...06patch-1) 02https://git.io/v952G
08:07 GitHub190 left
08:27 aidalgol joined
13:41 glennpratt joined
14:25 glennpratt joined
14:31 glennpratt joined
14:43 Bish joined
14:43 <Bish> hi, is there a Sequel.ilike which doesn't let the user use %% ?
14:45 <Rennex> Bish: there's escape_like
15:03 <Bish> Rennex: great
16:09 segfaulty joined
16:11 <segfaulty> on the off chance that this channel is actually active, is there any nice way to use use JSONB with sequel models?
16:15 <Rennex> segfaulty: i'm pretty sure there's a plugin or something, but i haven't used it. and this channel isn't dead, but answers may take a while
16:16 <segfaulty> Rennex: good to know, I'll see what I can come up with, thanks
16:17 <adam12> segfaulty: What are you looking for exactly? the pg_jsonb plugin will marshall data back into a special looking hash
16:17 <adam12> or you can use the serialization plugin.
16:21 <adam12> (or you can use both, to marshal into your own custom class)
16:31 Eiam joined
16:34 Eiam joined
16:43 <segfaulty> I first thought I needed the serialization plugin, but what I started implementing was for json not jsonb
16:44 <segfaulty> I think my confusion is just to the lack of docs specific to jsonb and the overlapping information
16:44 <segfaulty> if there is actually a 'pg_jsonb' extension that needs to be activated, then I would have missed that without you telling me
16:45 <segfaulty> I've looked at countless examples and docs and everything just refers to the 'pg_json' extension, even for jsonb
16:46 <segfaulty> I was hoping to be able to model the jsonb attributes themselves, but it seems like no one has implemented support for modeling json/jsonb attributes
16:48 <segfaulty> ideally, I'd like to be able to model the jsonb attributes so that the code base is better organized and implementation is cleaner, and then have the model serialized directly to jsonb without the overhead of turning the attributes into a hash when loading and saving
16:48 <segfaulty> but that would probably require a lot of effort
17:10 <adam12> segfaulty: Well, you have a few options, but nothing built into Sequel AFAIK
17:10 <adam12> I just went through this
17:11 <adam12> You can make your own method to define reader/writer's that delegate to your jsonb field.
17:12 <adam12> or you can make modules and then extend them into your model instances
17:12 <adam12> or you can use the serialization plugin to serialize in and out of a class you want.
17:13 <adam12> Here's a couple gists of what I was doing when experimenting. Maybe there's a hint in there for you: https://gist.github.com/adam12/69f70f0f8ad91efba74c4158874a21d9 https://gist.github.com/adam12/a1cca6c85e37469cd9d35d21ac23a3d6
17:23 <segfaulty> adam12: thanks, I'll see what I can come up with
17:24 <adam12> segfaulty: I ended up not using either of those, now that I look at it.
17:24 <segfaulty> will probably go with a more simple approach to minimize overhead, so this will be dealing with hundreds of thousands of inserts per day, as well as pulling a lot of that data out again
17:24 <adam12> I defined a small method that made the accessors for each class, then did STI
17:24 <adam12> but like I said, lots of ways to do this.
17:25 <adam12> but realistically, all you need is the pg_json plugin and it will marshal everything into a special Hash like structure for you. You might not need anything more than that in the interim.
17:25 <segfaulty> yeah
17:26 <segfaulty> I might eventually create my own abstraction, which replaces that default marshaling
17:26 <segfaulty> seems like a waste to have to use an intermediate hash if the ruby data is modeled in a class and the jsonb data is binary encoded
17:27 <segfaulty> but I probably won't have time to work on optimization like that for now
18:07 GitHub150 joined
18:07 <GitHub150> [13sequel] 15jeremyevans commented on issue #1357: No, the third argument to column should be an option hash. The only cases where we accept a regular argument in place of an options hash is for backwards compatibility. I don't want to introduce new cases. 02https://git.io/v9dAK
18:07 GitHub150 left
18:23 mwlang joined
18:27 GitHub99 joined
18:27 <GitHub99> [13sequel] 15jeremyevans commented on issue #1359: This makes sense to me. Thanks for the patch! 02https://git.io/v9djk
18:27 GitHub99 left
18:27 tercenya joined
18:28 GitHub153 joined
18:28 <GitHub153> [13sequel] 15jeremyevans pushed 1 new commit to 06master: 02https://git.io/v9djG
18:28 <GitHub153> 13sequel/06master 1429dc970 15Per Lundberg: Added note about the sequel-jdbc-as400 gem...
18:28 GitHub153 left
18:28 GitHub137 joined
18:28 <GitHub137> [13sequel] 15jeremyevans closed pull request #1359: Added note about the sequel-jdbc-as400 gem (06master...06patch-1) 02https://git.io/v952G
18:28 GitHub137 left
19:05 GitHub58 joined
19:05 <GitHub58> [13sequel] 15perlun commented on issue #1359: > Thanks for the patch!... 02https://git.io/v9FkJ
19:05 GitHub58 left
19:14 GitHub77 joined
19:14 <GitHub77> [13sequel] 15perlun commented on issue #1357: > No, the third argument to column should be an option hash. The only cases where we accept a regular argument in place of an options hash is for backwards compatibility. I don't want to introduce new cases.... 02https://git.io/v9FLB
19:14 GitHub77 left
19:14 GitHub95 joined
19:14 <GitHub95> [13sequel] 15perlun commented on issue #1357: > No, the third argument to column should be an option hash. The only cases where we accept a regular argument in place of an options hash is for backwards compatibility. I don't want to introduce new cases.... 02https://git.io/v9FLB
19:14 GitHub95 left
19:14 GitHub44 joined
19:14 <GitHub44> [13sequel] 15perlun commented on issue #1357: > No, the third argument to column should be an option hash. The only cases where we accept a regular argument in place of an options hash is for backwards compatibility. I don't want to introduce new cases.... 02https://git.io/v9FLB
19:14 GitHub44 left
19:15 <segfaulty> anyone know of a better way to do Sequel.like(:name, "%#{DB.literal(identifier)[1..-2]}%")
19:16 tercenya joined
19:19 tercenya joined
19:54 GitHub199 joined
19:54 <GitHub199> [13sequel] 15jeremyevans commented on issue #1357: I don't think littering the codebase with defensive error checks for nicer error messages is a worthy trade off. If the error messages are unhelpful in this case, they are probably unhelpful in all cases, and should be fixed upstream. 02https://git.io/v9F3k
19:54 GitHub199 left
19:59 GitHub62 joined
19:59 <GitHub62> [13sequel] 15jeremyevans commented on issue #1351: `:database_type == :oracle` is never going to be true, as the symbols aren't the same. You need to use `database_type` (the method), not `:database_type` (the symbol). As a general rule, if I said it was wrong before, reverting to it is probably not a wise idea. 02https://git.io/v9F3d
19:59 GitHub62 left
20:00 <jeremyevans> segfaulty: You want to remove the quotes from an identifier and use it in a like argument?
20:01 <jeremyevans> segfaulty: "%#{DB.dataset.with_quote_identifiers(false).literal(identifier)}%"
20:01 <jeremyevans> segfaulty: that's longer, but probably more correct for what you want
20:15 <segfaulty> I was hoping for a way to use ? with Sequel.like
20:16 <segfaulty> a safe way to interpolate the string in between %'s, preferably without string manipulation overhead
20:17 <jeremyevans> segfaulty: the way I gave is safe. Don't worry about the string manipulation overhead, that's probably not even measurable when you consider the database query
20:17 <jeremyevans> segfaulty: especially considering such a query cannot use an index (at least on most databases)
20:18 <segfaulty> I'm real OCD about performance, especially since what I'm working on needs to deal with hundreds of thousands of inserts per day, and pulling all that data out in different ways for a large number of users
20:18 <segfaulty> I end up writing my own libs in most cases because of poorly written gems
20:19 <segfaulty> my applications are eventmachine based, so I don't worry about the database latency since ruby will be doing other things in other fibers
20:19 <segfaulty> but anything that wastes CPU time can really affect performance
20:21 <segfaulty> I haven't benchmarked yet, but I assume that the block based DSL query syntax that Sequel provides has a fair amount of additional overhead, so as much as I'd love to have the syntactic sugar, I'll likely have to avoid using that for this project
20:24 <jeremyevans> segfaulty: You should probably benchmark the differences before just assuming the slowdown will be significant, but for fastest behavior using the prepared statement support would be recommended
20:24 <jeremyevans> segfaulty: and you can generate the prepared statements using the block-based DSL at startup time, with no slowdown at runtime
20:25 <segfaulty> yeah I plan on using prepared statements where possible, if they can be be generated from the block based DSL even better
20:54 GitHub9 joined
20:54 <GitHub9> [13sequel] 15jeremyevans commented on issue #1358: This isn't a bug, it's expected that an error would be logged in this case, since the query raises an exception. `table_exists?` is implemented by trying to select from the table, and returning false if doing so raises a `DatabaseError`. ... 02https://git.io/v9F8b
20:54 GitHub9 left
20:54 GitHub6 joined
20:54 <GitHub6> [13sequel] 15jeremyevans closed pull request #1358: Added test for incorrect error logging in `table_exists?` (06master...06fix/dont-log-errors-in-table-exists) 02https://git.io/v95B5
20:54 GitHub6 left
21:52 aidalgol joined
22:04 tercenya joined
22:46 <segfaulty> is there any nice way to say select('m1.*') since you can't say :'m1__*'
22:48 <jeremyevans> segfaulty: Sequel[:m1].*
22:51 <segfaulty> undefined method `[]' for Sequel:Module
22:51 <segfaulty> is that a recent feature, or have I broken it somehow?
22:57 <segfaulty> updated my bundles sequel and it works now, not even sure why it was outdated since there are no dependencies holding it back
23:28 glennpratt joined
23:32 glennpratt joined