<    March 2010    >
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:03 dimday joined
01:45 pietia joined
01:53 pietia_ joined
01:56 pietia joined
02:45 <injekt> Is there any reason sequel isn't compliant with the warnings flag enabled?
04:21 IceD^ joined
04:52 botanicus joined
05:22 merboutpost joined
07:11 quirkey joined
07:42 hydrow joined
07:44 s_dana joined
07:47 j_dana joined
08:03 <jeremyevans> injekt: Because ruby warns on fairly common idioms, such as assuming an uninitialized instance variable is nil
08:03 <jeremyevans> injekt: Fixing that requires setting the instance variable to nil in initialize, which is easy, but also kind of pointless
08:04 <jeremyevans> injekt: I'll accept patches to fix warnings, but I don't run with warnings enabled, it's likely things will creep in over time
08:11 mwlang joined
09:24 Swimming_Bird joined
09:53 bdimcheff joined
10:04 keithcascio joined
10:41 <injekt> jeremyevans: Ah ok, that makes sense. Thanks :)
10:46 keithcascio_ joined
10:48 <injekt> jeremyevans: What's the preferred way to implement a schema and a model? At the moment I'm just using Sequel::Model and the set_schema plugin, should I use migrations?
10:56 kevwil joined
12:00 Swimming_Bird joined
12:15 <jeremyevans> injekt: Migrations are preferred. Second would be DB.create_table statements before creating your model classes. set_schema would be last
12:20 <injekt> jeremyevans: Ah that's interesting to know
12:21 j_dana joined
12:22 brianmario joined
12:36 josh0x0 joined
12:36 ryan_ joined
12:37 <ryan_> hi , is there a recommended way to implement a localization schema?
12:37 <ryan_> the best solution i could come up with so far
12:37 <ryan_> is described here:
12:37 <ryan_> http://stackoverflow.com/questions/189680/database-localization
12:37 <ryan_> do you think that would play well with Sequel ? or is there a better design ?
12:39 <jeremyevans> ryan_: I like the voted up answer, since it's more normalized, but either that or the primary design should work fine
12:39 <ryan_> ok, thanks
12:40 <ryan_> for modeling it
12:40 <ryan_> in the code
12:41 <ryan_> any tricks you recommend ? Should i create a model class for each table and table_localization class ?
12:42 <jeremyevans> ryan_: That's how I would probably do it
12:44 <ryan_> ok, ill try that first. i figure this is a problem thats been solved a few times already.
12:46 <ryan_> The sequel toolkit has been a joy to use, great job - by the way. thanks for your response.
12:46 <jeremyevans> ryan_: Thanks. Good to hear. :)
13:14 hydrow joined
13:34 <Swimming_Bird> how would i do: "select (sum(wins)/sum(views)) as batting_average"
13:36 <Swimming_Bird> nevermind. i forgot about the block form of select
13:37 <Swimming_Bird> select{(sum(:views)/sum(:wins)).as(:batting_average)}
13:48 <Swimming_Bird> but i can't figure out how to do that with select_more
13:48 <Swimming_Bird> as in select *, foo as batting_average
13:53 <jeremyevans> Swimming_Bird: No good way currently, best is: select{['*'.lit, (sum(:views)/sum(:wins)).as(:batting_average)]}
13:53 <Swimming_Bird> ah
13:53 <jeremyevans> Swimming_Bird: This is because select_more is the same as select when no columns are selected
13:54 <jeremyevans> Swimming_Bird: We'd have to break back compat by changing select_more's semantics, or add another method (select_add?) that assumed adding columns to the wildcard if no columns were currently selected
13:58 <Swimming_Bird> do you like '*'.lit more than :*
14:19 <jeremyevans> Swimming_Bird: Well, '*'.lit works and :* does not (at least if you are quoting identifiers), so in this case, yes
14:20 <jeremyevans> Swimming_Bird: In most other cases I don't use lit, but there's no problem with lit if you are only targetting one database
14:20 <jeremyevans> Swimming_Bird: Or if you are sure the literal SQL works on all databases
14:21 <Swimming_Bird> only time i've ever used :* has been in the context of a select call and it's always worked there. i just wasnt sure if that was a more or less expensive call than lit
14:22 <jeremyevans> Swimming_Bird: There's no significant performance difference in most cases, but if the Database quotes identifiers, I don't think :* will work
14:44 <Swimming_Bird> jeremyevans: Model.find doesn't seem to be something you really promote using. is find_or_create ok or would it be better to roll my own using Model.[]
15:04 Mathetes joined
16:03 <jeremyevans> Swimming_Bird: Model.find is fine. I use Model[] more because it is shorter. find_or_create is fine, and I wouldn't roll your own unless you need specialized behavior
16:15 dimday joined
16:16 merboutpost joined
16:32 <Swimming_Bird> are there any hooks inside the initialize of a model? seems like after_initialize gets called whenever a model is loaded
16:32 <Swimming_Bird> whether it's new or not
16:38 pedrobelo joined
16:42 <dimday> Swimming_Bird: I guess you could put an if self.new? in the after_initialize to check if the model was new or not.
16:44 greg8si joined
16:47 merboutpost joined
17:45 dimday joined
18:35 <jeremyevans> dimday: That would be the Sequel way to handle it
19:18 merboutpost_ joined
19:48 greg8si joined
20:25 dkubb joined
20:25 dkubb joined
20:29 j_dana joined
21:45 quirkey joined
22:26 thomaz joined
22:46 dkubb joined
22:46 dkubb joined
22:46 dkubb joined