06:22 <somebee> any of you experiencing problems like this? http://gist.github.com/335171

06:34 <dbussink> somebee: using bundler?

06:34 <somebee> dbussink: yes

06:34 <somebee> dbussink: got similar errors with merb gems.. bundler seems to require everything in a random/crazy order or something

06:34 <dbussink> somebee: bundler doesn't load in the defined order

06:34 <dbussink> and some places miss a require 'dm-core'

06:35 <somebee> dbussink: so it is a bundler-bug?

06:35 <dbussink> somebee: no, but dm-serializer doens't require dm-core as it should

06:35 <dbussink> it has been fixed in http://github.com/datamapper/dm-more/commits/master

08:42 <snusnu> somebee, dbussink: gem declaration order is a funny issue :) http://github.com/carlhuda/bundler/issues#issue/107

08:43 <snusnu> also, the AS branch contains patches for the whole of dm-more already: http://github.com/snusnu/dm-more/commits/active_support

08:44 <snusnu> i have another comment on the issue in the works, but i haven't yet finished it, basically, i *really* think Bundler.require shouldn't be used, and therefore gem declaration order should be irrelevant anyway

08:47 <snusnu> but the patches in my dm-more fork aren't complete yet … i will remove the relevant requires from the spec_helpers as well, to make sure we have everything properly required when running the specs

08:47 <snusnu> and add Gemfiles for every gem in dm-more (and for dm-core)

10:53 <dkubb> dbussink: working on the UoW system right now, trying to figure out the correct order to fire events in

10:53 <dkubb> dbussink: here are some of the scenarios I've outlined: https://gist.github.com/6666d2818b14296a28ab

10:54 <dkubb> dbussink: so the object the event is firing on is on the left hand side. I'm trying to figure out this simple gp/parent/resource heirarchy first before I get into more advanced scenarios

10:54 <dkubb> dbussink: I wanted to ask your feedback since you use hooks and callbacks all the time

11:20 <tonyc> whoa!

11:20 <dkubb> tonyc: ?

11:21 <tonyc> 17:17 -!- whoahbot [~whoahbot@70.96.41.173] has joined #dm-hacking

11:21 <tonyc> heh

11:21 <dkubb> oh, heh

11:23 <dbussink> dkubb: and back :)

11:24 <dbussink> dkubb: fire away ;)

11:24 <dkubb> dbussink: heh

11:24 <dkubb> dbussink: ok, so check out the gist link I sent above

11:24 <dbussink> dkubb: you want to make the hooks explicit i assume?

11:24 <dbussink> i was already looking at it :)

11:24 <dbussink> dkubb: what is the object in each case where .save is called on?

11:25 <dbussink> resource?

11:25 <dkubb> dbussink: well, I haven't figured out exactly how they will be implemented, just trying to figure out at a high level in what order they should fire in

11:25 <dkubb> dbussink: yeah, resource is the object save is called on

11:25 <dbussink> i wonder whether in the last case before on that object should be called first then

11:26 <dbussink> if people want to do stuff there that might change the parent / grand parent

11:26 <dbussink> or do you feel that that belongs in a before valid? ?

11:26 <dkubb> dbussink: well, before valid is a better place to modify parents/gp's, since we never really gauranteed anything about before/after save except that it execute before and after saving an object

11:27 <dkubb> dbussink: so from the pov of the contract we've got with the users, all three cases are valid

11:28 <dkubb> dbussink: I'm trying to figure out if one approach is more inline with user expectation

11:28 <dkubb> dbussink: the order things fire before/after save will likely be the same order stuff fires for before/after validation too

11:28 <dbussink> dkubb: yeah, well, for me the last one feels a bit awkward

11:29 <dbussink> from what i can thing of now, the second scenario seems to make most sense

11:29 <dkubb> dbussink: from the pov of implementation, the last one would be simplest, but I think the second scenario is closer to what we have now

11:30 <dkubb> dbussink: actually #2 shouldn't be much harder to implement. if I set the dependencies on each before/after hook on the save method properly, then I think a stable topological sort should result in that ordering

11:31 <dkubb> dbussink: it's just that with #3, I'd bundle the hook executing up into the same method that saves the object

11:31 <dkubb> *hook execution

11:31 <dbussink> dkubb: yeah, but the behavior seems a bit weird to me

11:31 <dbussink> as the end user

11:31 <dkubb> with #2, I have to decouple the save command from the before and after hook command, and make sure that dependencies between them are set properly

11:32 <dkubb> which might not be that bad of an idea

11:32 <dkubb> I was thinking of separating out the command to set the FKs too.. have separate commands for each distinct action, with proper deps

11:33 <dkubb> I would just have the Set FK command specified as being dependent on a parent being saved, and make sure the child being saved was dependent on it

11:34 <dbussink> dkubb: that would make sense yeah

11:35 <dbussink> dkubb: which scenario has your preference?

11:35 <dkubb> dbussink: #2, but I didn't want to taint the results by saying that up-front :)

11:35 <dbussink> dkubb: hehe, good that i came to the same conclusion then ;)

11:59 <dbussink> dkubb: do you want to fire hooks when objects are not dirty etc?

11:59 <dkubb> dbussink: I dunno. current behavior does fire hooks when the object is not dirty, but it's graph is

12:03 <somebee> bundler is really screwing up dm right now ... vendor/gems/gems/dm-validations-0.10.3/lib/dm-validations/auto_validate.rb:4: uninitialized constant DataMapper::Property::OPTIONS (NameError)

12:03 <somebee> or maybe it's the other way around

12:03 <somebee> atleast I cannot deploy

12:05 <dbussink> dkubb: well, because that is an issue in the pep upgrade from what i can tell

12:05 <dbussink> dkubb: i think they should fire at least on the object .save is called on if the whole isn't dirty

12:05 <dbussink> but not on any other objects

12:06 <dkubb> dbussink: doesn't that seem strange to be inconsistent like that?

12:06 <dkubb> dbussink: like to make a special exception for the top level only

12:16 <dbussink> dkubb: well, if you call .save on an object i'd probably expect hooks to be called

12:23 <dbussink> dkubb: although a before :valid? could be used there

12:24 <dbussink> dkubb: to set for example a certain field based on ivars set

12:24 <dbussink> there was an example of it yesterday actually

12:24 <dbussink> somebody wanted to do a day, month, year set on an object

12:24 <dbussink> and make a birth date out of it in a before valid? and set that on the birth date property

12:35 <dkubb> dbussink: yeah, I think I will probably call hooks on an object that's saved regardless of whether its dirty or not. the main problem before was that hooks were being called multiple times.. that won't happen now because I'll only have unique commands in the UoW