02:17
ashley_moran joined
06:20
<g0bl1n>
if I want to get a list for all rows of only 2 fields of a table, what is the best approach ? all(:active => true, :order => [:acronym.asc]) or should I refer that I only need the :name and :acronym result fields ?
06:26
<g0bl1n>
I mean, what will waste more resources ? getting all, or a subset ?
06:26
<g0bl1n>
of fields, I'm referring to fields, not rows
06:35
<namelessjon>
g0bl1n: Well, all of then very expensive fields (such as large text fields) should go due to lazy loading. Still, :fields might make things quicker.
06:37
<g0bl1n>
ok, thanks, I'll use :fields
07:05
<path[l]>
hey guys, any idea when 10.3.3 comes out?
08:41
<snusnu>
path[l]: i guess it's safe to say rather soon .. maybe within a couple of weeks or so
08:45
<snusnu>
path[l]: assuming you mean 0.10.3 and not 10.3.3
08:46
<path[l]>
haha yeah
08:48
<namelessjon>
snusnu: It already does :)
08:48
<snusnu>
namelessjon: you mean dm-gen :?
08:49
<namelessjon>
snusnu: yeah
08:49
<snusnu>
namelessjon: cool, then i'll rip out dm-is-example
08:49
<snusnu>
namelessjon: and include dm-gen?
08:49
<snusnu>
namelessjon: at least below the datamapper account?
08:50
<snusnu>
namelessjon: not sure if adding things to dm-more is the right thing to do … we'll be splitting the gems up eventually i guess
08:50
<snusnu>
namelessjon: probably keeping dm-more with git submodules around, not sure bout that ..
10:01
<snusnu>
sickill: hey mind a quick question on merb to rails3 ?
10:19
<dkubb>
snusnu: yeah, I think having a single huge metagem like dm-more makes it less likely for people to fork and contribute
10:24
<snusnu>
dkubb: yeah .. btw, i wanna work on the AS stuff today … also i finally forced myself to install jruby(-head) and ruby-head
10:24
<dkubb>
snusnu: very cool. I'm working on the Unit of Work stuff today because I need it for the project I'm working on
10:24
<snusnu>
dkubb: i noted that jruby-1.4 doesn't install RG-1.3.6 with (master)rvm tho
10:25
<dkubb>
snusnu: I've almost got it working, but I'm having trouble getting events (hooks) to fire in the correct order
10:25
<snusnu>
dkubb: which means latest bundler doesn't work on 1.4.0 .. or at least that's my conclusion after fiddling with jruby for the first time
10:25
<dkubb>
snusnu: the guys in #jruby are pretty helpful
10:26
<snusnu>
dkubb: that sounds cool, looking forward to first codes of UoW
10:26
<snusnu>
dkubb: good idea, i'll drop in over there
10:27
<dkubb>
snusnu: the event system probably needs some reworking too, since it assumes a single method will be wrapped, yet for UoW to work properly, I need to be able to fire the before hook, do some stuff, then fire the after hook.. and "stuff" wouldn't be limited to what I can wrap in a single method
10:28
<snusnu>
dkubb: so you're thinking of taking a stab at the proper lifecycle hooks too?
10:28
tjholowaychuk joined
10:28
<dkubb>
I could be recursing down several laters so: fire before hook (self), fire before hook (parent), fire before hook (grand parent), save gp, fire after hook (gp), fire after hook (parent), fire after hook (self)
10:29
<snusnu>
dkubb: also, i found it kinda funny how people read your comment as "close this in bundler, it's fixed in dm" :P
10:31
<dkubb>
this is a simple scenario when saving an object graph. just trying to coordinate the hooks
10:32
<dkubb>
validation would be checked prior to doing anything, so step 0
10:33
<snusnu>
dkubb: hmm .. i'm kinda undecided if firing before hooks should be gp->p->r ? .. after all, the first thing that really gets saved is the gp ?
10:34
<dkubb>
snusnu: yeah, I'm not sure either. some people were relying on the hooks firing in the resource before doing anything to the parent/gp, but I don't know if that should be the expected behavior
10:35
<snusnu>
dkubb: tbh, if gp is saved first, i would expect it's before hooks to be run first .. now i haven't thought deeply about it .. but what if the before resource hooks rely on stuff established in gp or p ?
10:41
<snusnu>
dkubb: the third one seems the most logical to me .. it does everything at the stage i would expect it to happen (again, without having thought deeply about possible consequences)
10:44
<dkubb>
snusnu: yeah, my gut feeling is that the last one works correctly
10:45
<dkubb>
snusnu: however, I have seen cases where people created hooks on the object to set default values for the gp's and stuff, but I think that could also be done in validation anyway, and not the before(:save) phase
10:45
<dkubb>
er, done in before(:validation) I mean (yes, I want to add this named hook in)
10:48
<snusnu>
dkubb: sounds good
11:14
<dkubb>
snusnu: actually I think the middle one matches how things work right now
11:18
<snusnu>
dkubb: hmm, i avoid hooks whenever possible (so far) so i really can't say for sure without thinking more about it … i still think the third one matches my expectations more closely .. like, when i wanna write hooks in a model, i wanna write it in a way that doesn't assume the resource always being saved as part of some object graph .. i'd expect the hooks to fire right before/after that specific resource is saved/created/val
11:18
freemonttroll joined
11:18
<freemonttroll>
I get this mysterious error when I try to launch Integrity with do_mysql gem already installed: mysql_adapter.rb:3:in `require': no such file to load -- do_mysql (LoadError). What am I doing wrong?
11:20
<snusnu>
freemonttroll: damnit i remember seeing that, but not the solution .. now that wasn't really helpful, right? .. i do know there's a solution to this tho :)
11:20
<freemonttroll>
snusnu, heh
11:21
<dkubb>
freemonttroll: I wonder if there was a problem compiling do_mysql on your system
11:22
<freemonttroll>
dkubb, nope, it compiled native extensions w/out problems
11:22
<dkubb>
freemonttroll: so something like this works: ruby -e 'require "rubygems"; require "do_mysql"'
11:33
<snusnu>
dkubb: thinking about the Gemfile for dm-core .. you think it's good to put a dep on AS-3.0.0.beta1 from git in there, and no extlib?
11:34
<snusnu>
dkubb: i wanna try keeping my system gems "clean" .. that is running from bundler alone … so in order to run specs and such, i need AS part of the bundle
11:34
<dkubb>
snusnu: won't people using the Gemfile likely be closer to running on the cutting edge? in which case AS might be closer to what they are using
11:35
<snusnu>
dkubb: yeah, that was part of the reasoning too .. the Gemfile is for setting up a dev env .. no use for extlib there anymore (soon)
11:35
<irjudson1>
Gemfile.production / Gemfile.edge
11:35
<irjudson1>
to reduce scary
11:35
<snusnu>
irjudson1: well, AS will be "production" soon .. extlib's just there to support merb
11:36
<irjudson1>
yeah, the default should be the forward looking one, I was mostly just suggesting a "fallback" that's safe and known to work
11:36
<dkubb>
snusnu: how will AS work with people running DM with Rails 2?
11:36
<snusnu>
an issue i see is that while AS would be in the Gemfile .. it wouldn't be a hard runtime dep .. extlib neither .. both would be (the so much loved) optional deps
11:36
<snusnu>
dkubb: lol, probably not at all
11:37
<dkubb>
snusnu: optional deps aren't part of the Gemfile, right?
11:37
<dkubb>
er, not yet I mean
11:37
<snusnu>
dkubb: rg doesn't know how to handle them, so no
11:38
<dkubb>
snusnu: do you think it would be possible to get Rails 2 and DM w/AS to work? I'm fine with doing the work if it's even possible
11:38
<snusnu>
dkubb: as soon as we have a hard dep on AS, it'll be 3.0 anyway .. so if rails-2.x won't be compatible with that .. i wonder what we should do
11:38
<dkubb>
but I don't know too much about the differences between AS 2 and 3
11:38
<snusnu>
me neither dkubb
11:38
<dkubb>
snusnu: maybe I'll ask wycats about it. it's not like we use a ton of AS tho
11:39
<snusnu>
dkubb: yeah, basically: singleton_class/camelcase/singularize/pluralize .. i almost think that's it
11:39
<snusnu>
dkubb: we "could" use more tho, i guess
11:39
<snusnu>
dkubb: and we probably should
11:40
<snusnu>
dkubb: scratch the probably should .. but remember talking about trying to use more of AS features where that makes sense?
11:40
<dkubb>
snusnu: yeah, after we drop the extlib dep completely I will probably start to refactor the code to use some of the helper methods defined in AS
11:40
<dkubb>
snusnu: yeah, if we can cut code out, then I think we should
11:41
<dkubb>
some of the methods to define class/instance accessors look pretty useful
11:41
<dkubb>
especially the ones that work via inheritance. I can probably cut out 100+ lines right there
11:47
<dkubb>
careo: you've said before that alot of your logic lives in before/after hooks. if I'm saving a Resource, which order would you expect the hooks to fire in, in relation to saving the grand parent, parent, and resource that #save was called on:
https://gist.github.com/6666d2818b14296a28ab
11:48
<snusnu>
dkubb: are you fine with running specs using bundle exec once we have a Gemfile .. or should we put the bundler loading stanza into the Rakefile and spec_helper(s)
11:48
<snusnu>
dkubb: i'd go with bundle exec and not putting any bundle related code into the lib itself
11:49
<dkubb>
snusnu: yeah, I wouldn't want to tightly couple DM with bundler
11:49
<snusnu>
dkubb: although i think it's kinda fine to have it in rakefile and spec_helpers .. fine, but not necessary
11:49
<dkubb>
snusnu: it's fine to have it as an option, like we do with a gemspec, but I dunno if we want to make stuff not work without bundler
11:50
<snusnu>
dkubb: exactly
11:50
<snusnu>
dkubb: i'm all for bundle exec .. just wanted to doublecheck
11:51
<snusnu>
dkubb: ADAPTERS=sqlite3 bundle exec rake spec is green (i expected that, but haven't checked in a while :)
11:52
<snusnu>
dkubb: maybe we should just put extlib AND active_support into the gemfile .. dm-core itself anyway first tries to require AS, and if it can't fall back to extlib .. no way of requiring them both at the same time, which we absolutely don't want
11:52
<careo>
dkubb: hmm.
11:53
<snusnu>
dkubb: also, i think we need to drop the extlib *dependency* completely, and also not have one on AS … which basically hinders an "out of the box" experience? since we can't force one or the other to be installed along with a gem install dm-core …. hmm
11:54
<snusnu>
dkubb: bundler makes that pain go away .. but as long as extlib isn't completely dropped and we rely on AS, installing with rubygems alone will probably be a bit painful?
11:55
<dkubb>
snusnu: for now I'd probably say to require both. won't dropping extlib at some future point in time, and keep the dep to AS work out?
11:56
<snusnu>
dkubb: heh, that's an option actually, so dm-core will depend on both extlib/AS .. but will guarantee that both will never be required at the same time?
11:56
<snusnu>
dkubb: hmmm
11:56
<dkubb>
snusnu: hmm, I dunno
11:57
<dkubb>
snusnu: I mean we want minimum deps (of course), and we want to move to AS soon (but we don't want to force things along until we've had a chance to test it out)
11:57
<dkubb>
snusnu: we also want to give some time for the frameworks based on extlib to catch up
11:57
<snusnu>
dkubb: that would make it impossible to do the "feature detection" like we do now … if AS gets installed, it'll always be possible to require it .. so we missed the chance to fallback to extlib
11:58
<dkubb>
snusnu: if we just have a hard dep on extlib, from the pov of someone using DM all along, nothing will have changed. it's just that for people using Rails + DM, they'll be on AS
11:58
<snusnu>
dkubb: right, and if someone wants to use it with rails, he/she will have to install via bundler
11:58
<snusnu>
dkubb: which fetches AS, and makes dm happy
11:59
<snusnu>
dkubb: that should work?
11:59
<dkubb>
snusnu: I think so
11:59
<snusnu>
dkubb: yeah me too, let's do that
12:25
<namelessjon>
dkubb: I'm having a problem running yardstick. It fails with "can't convert Pathname into String (TypeError)"
12:25
<careo>
dkubb: so, looking at your gist, I'm not sure I follow your question. do you mean does the order there make sense?
12:27
<careo>
oh. now that I actually LOOK at your gist, I see you have three different orders.
12:27
<careo>
the 1st one makes the most sense to me
12:32
<dkubb>
careo: heh, people seem to prefer 1 or 2
12:32
<dkubb>
namelessjon: ok, I'll check it out
12:32
<namelessjon>
dkubb: This is using yardstick 0.1.0, yard 0.5.3
12:33
<dkubb>
namelessjon: just running "rake spec", or running the bin?
12:33
<namelessjon>
dkubb: yardstick path/to/file
12:33
<dkubb>
namelessjon: kk
12:36
<careo>
dkubb: yeah, it makes sense to me that *any* before hook that would possibly fire, should fire before any saving happens
12:36
<careo>
and then any after hooks should fire only after everything has been saved
12:39
<dkubb>
careo: you know, I was talking about this in #dm-hacking and leaning towards #2, but I'm beginning to think #1 is better all around
12:40
<dkubb>
if you replace "save" with "valid" or other hooks, then I think it also makes the most sense
12:41
<careo>
dkubb: yeah. like if I have an after save hook that sends a message about the new record, I don't want that to be wrong if a later hook ends up firing and throwing an exception
12:42
<dkubb>
#1 and #2 are correct from the pov of the contract we have in our API, but grouping common things together as much as possible seems like an approach that is easier to reason about
12:43
<dkubb>
this is also the simplest example, there will be cases where an object graph saves 20 objects, parents, children, grand parents, sets FKs between parent/child, executes before/after hooks, etc
12:43
<careo>
like, all of the before stuff should be before anything touches the db. in case you have something to do before the db is touched for whatever reason
12:44
<dkubb>
a large graph will look somewhat the same as this, except maybe the "Set FK" commands might be between each save command
12:45
<dkubb>
careo: although what about the scenario where the GP after save hook wants to do something to it's children?
12:45
<dkubb>
careo: in that case #2 will be more what you'd want
12:45
<careo>
do something to it before it's saved?
12:45
<dkubb>
careo: yeah
12:45
<dkubb>
careo: like set defaults or something
12:46
<careo>
well, then that's why you set a default on the property ;)
12:46
<dkubb>
I dunno if this is a valid use case, just throwing it out there
12:46
<careo>
dkubb: either way, it's a really hard thing to noodle about
12:47
<careo>
so, in my case I have models that update one property if another has been changed. then an observer that runs before/after save and after destroy to create event records based on the change in that record
12:48
<careo>
and then another observer that decides if it needs to create additional records based on the attributes of the model
12:48
<dkubb>
I think there is agreement that before hooks should all fire before saving anything, and that the resource, parent and gp should fire in that order
12:49
<careo>
yeah. that's the easiest to think about
12:49
<dkubb>
I also think that gp should save before parent, which should save before the resource, because we need to do that to setup FKs properly
12:49
<careo>
so you at least get guarantees that all the before hooks fire before the database can yell at you
12:49
<dkubb>
so the question really is that if the after hook should fire immediate after the action, or if it should be deferred to the very end
12:49
<careo>
and that all the after hooks will happen after the database has had a chance to yell at you
12:50
<careo>
so, imagine it's in a transaction
12:50
<careo>
then if the parent's after save hook does something that says "okay, I know for sure X has happened in the database"
12:50
<dkubb>
it's also clear that the after hooks should fire in the reverse order from the way the before hooks fired
12:51
<careo>
but then the child's save explodes
12:51
<careo>
then whatever action the parent's after save hook took based on the new state in the database is now invalid
12:51
<dkubb>
careo: yeah, but in the case of say the gp's after save hook, should it even know anything about the parent hook? should it just know about it's own object and any dependencies it has?
12:52
<careo>
dkubb: right, I think that's my point...
12:52
<dkubb>
careo: of course the parent hook would need to know about the parent and gp, since the gp is a dependency of it
12:52
<careo>
not sure if it is or not. I'm still on my 1st cup of joe
12:52
<dkubb>
careo: ok, hmm.. I was sort of debating from the pov that #2 might be closer to what we'd want, but I'm not 100% sure either way
12:53
<careo>
yeah. so that means that the child could potentially do something that breaks what the parent hook did
12:53
<careo>
if the save fails
12:53
<careo>
like, if you think of it as a "going to save X" hook and a "I saved X" hook
12:53
<dkubb>
careo: there is the opportunity for failure in any stage to cause the transaction to be invalid and rollback
12:53
<careo>
but really, something later causes the transaction to rollback
12:54
<dkubb>
careo: a hook can even do more DB work too
12:54
<datka>
is it possible to have rdoc show the properties of a model?
12:54
<careo>
sure. but a hook doing more db work is a whole 'nother bag of hurt :)
12:54
<dkubb>
careo: that's one of the crazier scenarios i'm going to model later on, where before/after hooks modify the unit of work
12:55
<dkubb>
datka: I think it would be possible to write an rdoc plugin to do that, since the model properties are all totally introspectable
12:55
<careo>
dkubb: so, in my use case, I my observer creates an Event record based on changes to records
12:56
<careo>
and then in an after save hook on the event, I send an amqp message
12:56
<careo>
in that case, I can't rollback the sending of the message if the transaction fails
12:57
<dkubb>
snusnu: doesn't rdoc have some sort of plugin system?
12:57
<dkubb>
snusnu: although I generally would recommend YARD too
12:57
<snusnu>
dkubb: i was too fast with the no probably, tbh i dunno .. i never heard of something already written for dm tho ..
13:02
<dkubb>
careo: ahh, I see what you're getting at
13:03
<dkubb>
careo: my scenario about modifying the parent when the GP is saved is probably wrong too. the gp's hooks shouldn't assume that it's being saved with the parent object. for all it knows it's being saved by itself
13:04
<dkubb>
YARD > rdoc ... I don't even use rdoc much anymore
13:04
<dkubb>
there was talk at mwrc about updating ruby core/stdlib's docs using YARD, which would make for much nicer docs
13:04
<dkubb>
things would be much more consistent, and even testable
13:05
<dkubb>
the main problem with such a project would be organizing people to help (not too hard), and getting the ruby core team to "bless" the output (much harder due to the language/cultural gap)
13:07
<dkubb>
dbussink: ^^^ what do you think about this conversation? I know you rely on hooks alot too. can you see some problems with #1, or advantages that #2 gives us?
13:08
<dbussink>
dkubb: well, i think the concern that you don't know what called the hook is an important one
13:09
<dbussink>
i can't really see any issues directly with #1 atm
13:10
<dkubb>
the only thing you can't get with #1 is that you can't make changes in say the gp after save hook that affect the parent save command.. but then again, maybe you shouldn't be doing that anyway
13:10
<dbussink>
dkubb: don't want to make it much more complex, but maybe including children in the picture would make one solution more obviously correct compared to another?
13:11
<dbussink>
dkubb: i hope people aren't that dependent on behavior like that
13:12
<careo>
yeah. that doesn't seem like a feature that would end well for anyone
13:13
<dbussink>
dkubb: for one i think the most valuable thing is that the behavior is actually defined
13:13
<dkubb>
dbussink: if you think of the parent as being the object save is called on, neither approach seems to make much sense ot me
13:13
<dbussink>
and doesn't depend on current internal implementation
13:14
<dbussink>
dkubb: ok, imagine this scenario, an object with n children
13:14
<dkubb>
dbussink: yeah, that's why I'm thinking about this in the abstract first, and then will code the implementation to comply, complete with specs to enforce the order things happen in
13:14
<dbussink>
there's a after :save in that object, would you expect the children already to be saved in the after save?
13:14
<dbussink>
dkubb: or not yet saved?
13:15
<dkubb>
dbussink: children would have to be saved afterwards, since they may be dependent on something in the parent to be set, like the FK
13:15
<dkubb>
dbussink: oh, wait
13:15
<dbussink>
dkubb: well, scenario 1 would make the after :save executed after the children are saved
13:16
<dbussink>
not really sure if that is expected or not though
13:16
<dkubb>
lemme update the examples with a single child node
13:17
<dkubb>
hmm, this is weird, not sure where to put stuff
13:17
<careo>
I think the important thing is that you can think of the hooks in complete isolation too
13:20
<dkubb>
the idea I was going for was that a child is dependent on his parent being saved first
13:21
<careo>
yeah. I don't think you need to have children in there at all. since they won't be saved automatically as a result of calling save on the resource, right?
13:22
<dkubb>
I wonder though if the grand parent's before hooks should be before the parent before hooks
13:22
<dkubb>
careo: children are automatically saved as part of the object graph
13:22
<careo>
dkubb: ah right. yes. that makes sense
13:23
<dkubb>
careo: which allows stuff like this to work: Order.create(:reference => '12345', :items => [ { :name => 'Blue Widget' }, { :name => 'Red Widget' } ])
13:23
<dkubb>
dbussink: wdyt?
13:23
<careo>
so, what if a hook, for some bizarre reason, modifies part of the primary key of the record
13:24
<dkubb>
careo: good question. I don't know
13:24
<careo>
then I guess in that case, you'd want any such hooks to happen before any saves?
13:24
<dkubb>
hmm, looking at this, I wonder if the before hooks should be executed in the order: gp, parent, resource, child ?
13:25
<dkubb>
careo: yeah, except we can't really control what people do in those hooks. if they decide to modify the objects after it's already been saved, then the graph will need to be saved again to make it "clean"
13:26
<careo>
dkubb: but they're not modifying it after, they're doing it before. in a before hook ;)
13:27
<dbussink>
dkubb: i think that should start a new UoW then probably
13:27
<dbussink>
dkubb: what feels best in those alternatives to you?
13:27
<careo>
so, what if you have a before hook that does some sort of validity checking, and as a result of that it may want to abort the whole graph from saving
13:28
<dbussink>
careo: changing pk's is not an everyday thing, maybe blow up is the best in that case
13:28
<dkubb>
the difference with 3 is that it's just like #1, except the before hooks are executed in: gp, parent, resource, child ... same with #4, it's just like #2, with the gp/parent/resource/child
13:29
<dbussink>
dkubb: having that in inverse order probably makes more sense
13:29
<dbussink>
it's more logical anyway
13:30
<dkubb>
dbussink: in the implementation I was planning, the UoW would be created when Resource#save is called, and then the object graph "walked" and resources added to the UoW, and then it would be asked to commit itself
13:30
<dkubb>
dbussink: it would work out the dependencies and save them
13:31
<careo>
so in that case, does it make more sense to think of the before and after hooks as running before and after the entire unit is saved?
13:34
<dkubb>
dbussink: so you're vote is for 3 or 4?
13:34
<dbussink>
dkubb: probably yeah, mainly because of consistency
13:35
<dbussink>
although i can also see the other point from the hook itself
13:35
<careo>
dbussink: by inverse order, did you mean the after hooks would fire child -> resource -> parent -> grand parent
13:35
<dkubb>
careo: I think he means he prefers 3 to 1, and 4 to option 2
13:36
<careo>
3 and 1 look identical to me
13:36
<dkubb>
careo: look at the order of the before hooks
13:36
<careo>
yeah. 3 makes more sense to me too
13:37
<dkubb>
it is nice to not have any special cases for the resource that Resource#save is called on
13:37
<dkubb>
parents before children for before, save and after filters
13:38
<dkubb>
ok, I agree on 3 and 4 being better
13:38
<snusnu>
dkubb: looking through the AS branch .. it's rather broken in the extlib scenario atm … AS works fine .. extlib needs more work still .. i'm positive tho to have something usable before i go to bed today
13:38
<dkubb>
snusnu: ok, sounds great
13:39
<dkubb>
snusnu: maybe when you do merge this into the mainline, put it in next. I need to do a release from master with the fixes to make bundler happy
13:39
<dkubb>
s/mainline/main repo/
13:39
<snusnu>
dkubb: thinking of maybe really pulling in *everything* we need from extlib .. in order to be able to drop the dependency entirely ...
13:40
<snusnu>
dkubb: that's fine, the commit in my AS branch should apply without much hassle
13:40
<snusnu>
dkubb: i mean the one that fixes bundler for dm-more
13:40
<dkubb>
snusnu: in that case, we'd have inflections and others inside dm-core. wouldn't that be a duplicate of what we get from AS?
13:41
<snusnu>
dkubb: of course, but when running without AS we don't have that
13:41
<dkubb>
ok, I will remove scenario 1 and 2, and add a "set FK" command to see what that looks like
13:41
<snusnu>
dkubb: i'd put everything extlib related below dm-core/support/extlib
13:44
<dkubb>
snusnu: in the end though, we'd be deleting dm-core/support/extlib once we switch to AS, so it might be easier just to drop the dep when that time comes than to remove all the code and specs
13:45
<dkubb>
snusnu: I don't mind having the extlib dep for a period of time while we convert things over
13:45
<Tass`>
just wondering why DataMapper.auto_migrate! when requiring dm-core only gives me a NoMethodError
13:45
<careo>
dkubb: yeah, I like 3 more
13:46
<dkubb>
Tass`: auto_migrate is only available if one of your adapters that you setup has the ability to migrate
13:46
<Tass`>
dkubb, ah, oke
13:47
<dkubb>
I thought about stubbing it out and just having it explode if nothing is setup, but it's not common enough compared to other things
13:47
<snusnu>
dkubb: yeah it's probably fine, still have to try to remember why i started pulling in extlib code in the first place
13:47
<snusnu>
dkubb: i remember we agreed upon that, but i can't remember the reasoning behind that :)
13:47
<snusnu>
dkubb: maybe i should go home, eat something .. then continue
14:15
<dkubb>
which was previously option 3. I removed 1 and 2 because those don't feel as close as 3 and 4
14:27
<dbussink>
dkubb: cool :)
15:19
<irjudson>
#yardstick is emtpy
15:19
<irjudson>
'cept for me
15:23
<dkubb>
I always forget to join
15:44
hipertracker joined
17:44
hipertracker_ joined
17:55
<dkubb>
I need to refactor some of the Resource internals to make this less ugly, but I want to see if I can make it working with minimal changes first
18:50
<postmodern>
can the :default option for properties use a lambda?
18:52
<namelessjon>
postmodern: Yes
18:52
<namelessjon>
postmodern: It gets passed the resource and the property
18:56
<postmodern>
excellent!
19:07
<postmodern>
does DataMapper support generating COMMENT statements for MySQL?
19:14
<postmodern>
currently im working on creating models for an external database, based off someone's schema.sql file
19:40
<postmodern>
when a resource is loaded by DataMapper, it calls allocate
19:41
<postmodern>
i've overriden allocate to forcibly call initialize
19:41
<postmodern>
but the attributes for the resource are not being passed to initialize
19:41
<postmodern>
wait nm
19:48
<dkubb>
postmodern: yeah, you probably don't want to force allocate to call initialize. allocate is used to avoid calling initialize
19:49
<dkubb>
postmodern: there's no support for COMMENT statements in MySQL. What would you want to store?
19:52
<postmodern>
was just wondering if i could access the comments, but i don't really need them
19:52
<postmodern>
hmm yeah
19:53
<postmodern>
it appears i was overriding allocate() to make sure certain default ivars got set
19:53
<dkubb>
postmodern: ahh ok. yeah, you can always access them using raw SQL
19:53
<dkubb>
postmodern: why do that, why not set the :default for the property
19:53
<postmodern>
these are instance variables
19:54
<dkubb>
postmodern: or you can override initialize(), set the ivar, and then call suprt
19:54
<postmodern>
that probably shouldn't be in the database
19:54
<postmodern>
correct, but if i recall Model#load, only calls allocate
19:54
<dkubb>
ahh, that may be correct
19:55
<dkubb>
what we need is a way to mark a property as "virtual" so it's not persisted, yet we can define all the normal things on it, including defaults, types, etc
19:55
<postmodern>
ideally, i would want initialize always called with the Hash of attributes
19:55
<postmodern>
that would be nice
19:55
<postmodern>
im currently using a library sort of like virtual properties, Parameters
19:56
<postmodern>
which allows me to define parameters for a class/object, and add :default or :description options to them
19:56
<dkubb>
postmodern: do you have a link to that lib?
19:57
<postmodern>
dkubb, it integrates really well with command-line utils
19:57
<postmodern>
dkubb, i can just do obj.params = some_parsed_hash, and it will attempt to coerce values into specific types
19:57
<dkubb>
postmodern: ahh cool
19:58
<postmodern>
dkubb, and i can dump out all the descriptions for the params
19:58
<dkubb>
postmodern: actually one thing I've been thinking about for DM 2.0 is decoupling the front-end API for definining properties and relationships from persistence, so that you could use the DM style API for POROs
19:58
<dkubb>
postmodern: there would be a layer that introspects the class, and defines a mapping between it and the backend datastore
19:59
<postmodern>
currently though, i need some way to get Model#load to properly call initialize
20:00
<dkubb>
postmodern: you can always define your own load class method, call super, then call initialize on the return value, then return the value
20:01
<postmodern>
that's right, since load is from a module, i can call super
20:01
<postmodern>
that should work
20:05
<postmodern>
also is there a method like attributes, but also includes relation data?
20:10
<postmodern>
seems like datamapper needs to strictly define how initialize() is called
20:11
<postmodern>
Model.new() will call initialize with the attributes
20:12
<postmodern>
it could be changed, so that Model.new allocates the resource, populates the attributes/relations, then calls initialize with no arguments
20:53
<snusnu>
hey dkubb, metric_fu requires AS>=2.2.3 :/
20:54
<dkubb>
snusnu: how does that affect us? the dev deps?
20:54
<snusnu>
dkubb: and it looks like bundle exec always activates all gems in all groups
20:54
<dkubb>
snusnu: is that correct behavior?
20:55
<snusnu>
dkubb: actually, gimme a minute
20:55
<snusnu>
dkubb: i know i was wishing for something like bundle exec —without=foo,bar rake spec
20:55
<dkubb>
that sounds fishy. I can't imagine a case where I'd want to use *every* gem dep all at once, especially when I use explicit groups
20:55
<snusnu>
dkubb: s/was/am
20:55
<snusnu>
dkubb: yes, you can do bundle install —without foo bar
20:56
<snusnu>
dkubb: so exec should probably support it as well
20:56
<postmodern>
snusnu, quick dm-rails question, how would i specify multiple production repositories with dm-rails
20:56
<snusnu>
dkubb: the problem now is, that running bundle exec rake spec in dm-aggregates has AS-2.23 on the loadpath, and thus our prefer AS fallback to extlib doesn't work because AS is present
20:57
<snusnu>
dkubb: lemme check that again though by running a new bundle install
20:57
<snusnu>
dkubb: i wonder why it's not satisfied with 3.0.0.beta1 .. metric_fu's dep is >= 2.2.3
20:59
<snusnu>
dkubb: yes, when i comment out the AS 3.0.0.beta1 gem from the Gemfile .. then it just activates 2.2.3 and thus the tests won't run
21:00
<snusnu>
dkubb: i wonder if i should just remove metric_fu and stuff from the Gemfile for now
21:01
<snusnu>
postmodern: have a look at the README .. there's an example for multirepo database.yml
21:01
<snusnu>
postmodern: or do you mean something different?
21:03
<postmodern>
snusnu, ah i see, thank you
21:05
<snusnu>
dkubb: one way to work around is to do: bundle install —without quality; bundle exec rake spec
21:06
<snusnu>
dkubb: this means that when running specs, we'd need to temporarily disable the quality deps
21:06
<snusnu>
dkubb: imho bundle exec should support that .. i will ask over in #carlhuda
21:23
<snusnu>
dkubb: this is tricky shit .. actually, i only saw the problem in dm-more, because dm-core's first AS require requires a file that isn't present in AS-2.2.3 :P
21:23
<snusnu>
dkubb: i'll amend my "ready_to_merge" commit and pass it for you to review in a bit
21:42
<grandy>
hello, i just experienced a very odd issue... in a chainable finder method I use map and generate a hash, one key of which is set by calling an instance method ... as in map{|i| {:foo => i.foo}} ... inside foo there is a call to self.child_models and the resulting query uses an IN clause with a lot of different ids instead of just self's id, even though self was supposed to be one instance of hte class
21:44
<grandy>
anyone have any thoughts on this, or should i try to reproduce in a test case? just thought i'd mention it just in case it's a known or intended behavior
21:48
<bm5k>
anyone using custom property types?
22:07
<postmodern>
how does one set attributes in a resource now?
22:07
<postmodern>
attribute_set isn't working anymore for me
22:08
<postmodern>
im overriding the setting method for an attribute, to add extra white-space sanitization (on each_line of the text)
22:45
<postmodern>
ah wait, it was a scope issue
23:18
<bm5k>
is there a way to set default validations on a custom type? ie a default format?
23:46
<snusnu>
dkubb: phew
23:46
<snusnu>
dkubb: now including specs from extlib
23:46
<snusnu>
dkubb: everything passes with AS and extlib .. detailed instructions in the Gemfile
23:48
<snusnu>
dkubb: heh, it'd be cool if you could doublecheck them (maybe with more adapters too, i only ran sqlite3 so far .. it's too damn slow while devving to run the other adapters too :)
23:48
<dkubb>
snusnu: awesome. ok, feel free to merge it in. I'll run tests on my end with all the rubies I have installed too, just to make sure it's solid
23:49
<dkubb>
snusnu: merge it into next I mean
23:50
<snusnu>
dkubb: ok, then i'll push it to next now, and once you give me the ok (running more adapters,rubies and especially, the dev env install instructions with the mentioned "limitation") .. i'll push it to master :P
23:50
<snusnu>
dkubb: that most definitely won't happen before i get some 8 hours sleep or so :P
23:51
<dkubb>
snusnu: yeah, no rush. I'll run some specs on my end too
23:54
<snusnu>
dkubb: test the hell out of it! :)
23:54
<dkubb>
snusnu: hehe, I could've sworn you've committed lots to dm-core.. maybe that was on the "satellite" gems and not core
23:54
<dkubb>
snusnu: trust me, I will
23:55
<snusnu>
dkubb: and of course i wanted to say *my* first substantial commit .. not *the* first … :P
23:55
<dkubb>
I've almost got a code spike for a UoW working
23:55
<dkubb>
it's amazing to see all the commands self assemble themselves, and then execute in the correct order
23:56
<snusnu>
dkubb: hehe very awesome!