01:12
<wycats>
dbussink: can you guys PLEASE fix the missing require in dm-timestamps?
01:12
<wycats>
I'm tired of hearing about how it's a bundler bug :(
02:13
<dbussink>
wycats: which missing require, haven't heard anything about it
02:14
<dbussink>
or is there a lighthouse ticket for it?
02:14
<wycats>
dbussink: dm-timestamps needs to require dm-core
02:18
<dbussink>
wycats: ah, looks like snusnu already committed a fix for it
12:46
<dkubb>
snusnu: I'm going to work on a "state of the union" type email to send to the mailing list
12:46
<dkubb>
snusnu: I'll announce that we're forming a "core team" officially, and that you're part of it (I don't think it matters if we talk about it in this channel tho)
12:47
<dkubb>
snusnu: I'll mention that we're looking for a 1.0 by RailsConf, and tell people where to find the roadmap to see if they can contribute
12:47
<dkubb>
snusnu: I'll also mention your project to setup a base package for all web frameworks
12:47
<dkubb>
snusnu: anything else you think I should mention?
12:47
<dkubb>
snusnu: I guess I could give people a sneak peek of veritas too
12:51
<wycats>
dkubb: plz release something with require dm-core fixed :P
12:51
<wycats>
people keep blaming bundler
12:51
<wycats>
and they don't understand why it's not our fault :(
12:51
<dkubb>
wycats: snusnu is going to push something into the mainline with the fix tonight
12:51
<wycats>
dkubb: it would be helpful if you guys publicly explained what was up
12:51
<wycats>
so I could point to it
12:51
<dkubb>
wycats: I can do that
12:52
<dkubb>
wycats: is it happeninng alot? I haven't seen anyone ask about it on the ML yet
12:53
<wycats>
it's a "bundler bug"
12:53
<wycats>
don't you see?
12:53
<wycats>
I'm not kidding
12:53
<snusnu>
dkubb: sounds good, nothing particular comes to my mind, the one other goal i have on the radar, is to make dana fully compatible with rails (whatever that takes)
12:53
<wycats>
people don't realize it's a DM bug
12:54
<snusnu>
wycats: i have a fix for dm-more in my branch, i'll push that soon
12:54
<wycats>
"+1 (this is absolutely killing us with datamapper)"
12:54
<wycats>
what people want is the ability to control the order so that they can put dm-core first
12:54
<wycats>
which is ok I guess
12:54
<wycats>
except people shouldn't HAVE to know
12:55
<snusnu>
wycats: i'm, not convinced by that yet
12:55
<wycats>
"Just wondering if there's an update on the fix btab proposed, I was having the same issue with ordering when running a locked bundle (especially with DataMapper)."
12:55
<snusnu>
wycats: i mean, that the Gemfile should keep the order
12:55
<wycats>
"+1 here too. Just ran into this with DataMapper where dm-timestamps is getting loaded before dm-core."
12:55
<dkubb>
wycats: I will add a comment to that right now
12:55
<dkubb>
wycats: then you can say "see, Dan says it's his fault"
12:55
<snusnu>
wycats: and with dm-rails, this is no problem *right now already*
12:55
<wycats>
I don't want to say that
12:55
<dkubb>
wycats: then I'll post something about it on the ML
12:55
<wycats>
I want people to stop telling me that this is an obvious Bundler bug
12:56
<wycats>
which they CONSTANTLY tell me
12:56
<dkubb>
wycats: but it is :)
12:56
<namelessjon>
wycats: Well, I kinda think that bundler should require things in dependency order. It has the knowledge to do that (surely?)
12:56
<snusnu>
i'm not sure it should do that ...
12:56
<wycats>
namelessjon: not everything specifies dependencies
12:56
<wycats>
it's a clusterfuck in actual real gems
12:56
<wycats>
people need to require the things they need
12:56
<snusnu>
they should
12:57
<snusnu>
it just feels weird to have the "gem" command do a require .. in a file that feels like a config file .. but actually is executable code cause it gets evaled
12:57
<snusnu>
i want "gem" to activate it
12:57
<snusnu>
then do require to require it
12:58
<dkubb>
I would think that if there are no depdencies specified anywhere, then people shouldn't be upset if gems are required in the wrong order, but if there are deps, then requiring in that order makes sense
12:58
<namelessjon>
wycats: Well, I'm not saying bundler should magically work out deps, just honour those it does know of.
12:58
<dkubb>
I am ok with doing a work-around to DM to make life easier, but this problem won't be isolated to just DM code
12:59
<snusnu>
to me it is confusing that the order in which i call "gem" has any consequence on the order stuff gets *required*
12:59
<wycats>
can you guys join #carlhuda
12:59
<wycats>
it's actually a nasty problem
12:59
<dkubb>
wycats: I am curious about the problem, because I am actually about to try tackling it in a different way with saving Resources in the right dependent order
14:02
<dkubb>
dbussink: I'm going to use tsort to sort the object dependencies so things are saved in the correct order
14:03
<dkubb>
dbussink: what I'm actually going to do is wrap each resource in a Command-type object like Create, Update and Destroy, which will know 2 things: the resource it should act on, and other commands it is dependent on
14:03
<dbussink>
dkubb: is tsort guaranteed to be stable?
14:03
<dkubb>
dbussink: so the unit of work will simply sort these command objects according to their dependencies, and then begin executing them in order. it'll also identify cycles before doing anything, allowing me to bail out early
14:04
<dkubb>
dbussink: I'm not sure yet. the API shows a few helper methods you have to implement, one for sorting each node, and one for sorting each child node
14:04
<dkubb>
dbussink: if I can make it so the nodes are returned in insertion order then I can make it stable
14:05
<dkubb>
dbussink: I know what order each node was inserted in, so when two nodes are given equal weight, I can use their insert order as a tie breaker
14:06
<dbussink>
dkubb: ah, yeah, if you track that too then you can do it that way
14:06
<dkubb>
so if A, B and C are added, and none dependent on the other, they will be saved in that order
14:07
<dkubb>
the tricky part will be when executing hooks and modifying the object graph. it's almost like i will need to recalculate the dependencies after each hook is executed
14:07
<dkubb>
because the hooks themselves could create, update, or destroy objects in the graph right in the middle of me executing the chain
14:08
<dkubb>
I'm not sure yet if that should result in a separate unit of work being executed afterwards or in the middle
14:09
<dbussink>
dkubb: hmm, maybe trying to work out those scenario's is the only way to reason about it
14:10
<dbussink>
because it also depends on whether things are related through a has n, belongs_to or whatever
14:10
<dkubb>
my rough API probably has alot of holes in it. for example, if I'm using cascading deletes, then one Delete command might be dependent on another, and so on
14:10
<dkubb>
I'm not sure yet how to represent that kind of dependency
14:10
<dbussink>
but maybe the separete unit of work is not a bad idea
14:11
<dbussink>
that's either executed before or after
14:11
<dkubb>
I mean, the UoW works underneath everything, the end user does not see it, but the API should be clean anyway because I am going to use it
14:12
<dkubb>
and if something screws up, I want it to be clear when it's a misuse of the API that caused it or a bug. a nice API will make API misuse simpler to catch
14:14
<dkubb>
dbussink: actually, I'm thinking that any changes to the objects inside a hook would need to create a separate UoW and execute it right there
14:14
<dbussink>
dkubb: disregarding the state in the current UoW?
14:14
<dbussink>
might actually be closest to what people expect
14:14
<dkubb>
dbussink: because in some cases the hooks check return values of #save and #destroy
14:16
<dkubb>
dbussink: the plan with the UoW was that when you call #save or #destroy, it'd see if a UoW was being used, and if not create one, and then walk the object graph and add each modifying object to the queue
14:16
<dkubb>
s/queue/UoW/
14:16
<dbussink>
so not saving them right there at that moment?
14:17
<dbussink>
if you do a separate save that won't work then probably
14:17
<dkubb>
dbussink: well, from the pov of the user all this happens inside the method
14:17
<dbussink>
and i wonder if people expect that limitation
14:17
<dkubb>
dbussink: I'm mostly just talking about what we'd be doing internally
14:18
<dbussink>
dkubb: well, i was thinking about what people can do in a before / after hook
14:18
<dbussink>
if they do a save and check return value like you suggested, you'd need to handle a separate UoW at that point
14:18
<dkubb>
yeah, I think you're right. the inner and outer UoW wouldn't know anything about each other
14:19
<dkubb>
of course we'd want to handle n-level deep UoW's
14:19
<dkubb>
since saving in a hook could trigger another hook to save, and so on
14:21
<dbussink>
down the rabbit hole
14:21
<dkubb>
in my UoW class, I separate new/dirty/deleted resources from each other, but I think that's wrong. any command could be dependent on any other command
14:21
<dbussink>
the only thing i see is possibly conflicts because you change an object in the hook that is also registered in the current UoW
14:21
<dkubb>
yeah, I was thinking that too
14:21
<dbussink>
a delete could make something as updating an fk to nil
14:22
<dkubb>
so in that case the Update command is dependent on a Delete command
14:22
<dbussink>
delete dependent in update right?
14:23
<dbussink>
with dependent you mean that the update needs to go before the delete?
14:23
<dkubb>
I should use the term dependent and depends on
14:23
<dkubb>
so Update depends on the Delete
14:23
<dkubb>
while the Update is a dependent of Delete
14:24
<dkubb>
hope that makes sense
14:24
<dbussink>
naming things is hard :)
14:24
<dbussink>
dm-constraints should also be able to hook into UoW
14:25
<dbussink>
so it can register stuff as depending on that
14:26
<dbussink>
validations are going to be UoW wide?
14:27
<dbussink>
and for constraints that would mean that validation fails where a non cascading delete is present right?
14:27
<dkubb>
dbussink: yeah, I think we need to be able to ask the UoW if all the Command objects are valid
14:27
<dkubb>
dbussink: the hard part is that some Commands aren't valid until it's dependents are executed
14:28
<dkubb>
dbussink: like for example, when you create a parent with children, the children have no FKs until the parent is saved
14:29
<dbussink>
dkubb: well, i think that's a case that should be handled
14:29
<dkubb>
dbussink: so if you asked the children if they are valid before anything is saved, they wouldn't be
14:29
<dbussink>
dkubb: i think we talked about a special belongs-to validation that can handle this
14:29
<dbussink>
that for a new resource as a fk, it would allow an nil fk and see that as valid
14:30
<dbussink>
people can always bite themselves, but i think this case warrants special treatment
14:30
<dkubb>
dbussink: yeah, perhaps in those cases I can wrap the Create Command in something like SetForeignKey, and it'd know that the create command is valid or not even tho the FK isn't set
14:30
<dbussink>
but not letting it be a regular validation on an fk property
14:30
<dbussink>
i think the cases are fairly limited
14:31
<dkubb>
dbussink: when SetForeignKey command executes, it could get the FK value from the parent, set the object, and then ask the Command it contains to execute
14:31
<dkubb>
dbussink: multiple FK commands could be wrapped inside each other for cases where a resource has multiple parents
14:31
<dbussink>
dkubb: yeah, but that's separated from the validation then
14:31
<dkubb>
dbussink: right
14:31
<dkubb>
this is tricky to get right
14:32
<dkubb>
I want to make sure the process is simpler internally than DM now
14:32
<dkubb>
right now we use recursion to save things in the correct order, and it works sort of ok, except when there are circular dependencies
14:33
<dkubb>
I think having Command objects for each of the primary actions we execute when persisting makes sense and should be relatively easy to follow
14:33
<dbussink>
as long as it's pretty straightforward and linear it's already easier to comprehend
14:33
<dkubb>
and having dependencies between them also makes sense
14:35
<dkubb>
going to crack open PoEAA and see how it recommends this is dealt with
14:35
<dbussink>
does sqlalchemy have some code inspiration on this?
14:37
<dkubb>
dbussink: I've found some places where tsort of implemented, although I am just going to try to use the TSort lib in ruby-core first
14:38
<dkubb>
dbussink: I've also read on their ML that FK setting is part of the sequence of commands that are executed
14:38
<dbussink>
i'm going to look at how old that code is, some things are not really kept up to date in core
14:38
<dbussink>
dkubb: ah, so also some special treatment
14:38
<dkubb>
dbussink: yeah
14:39
<dkubb>
dbussink: dm-constraints doesn't have anything to cascade updates to FKs does it?
14:39
<dkubb>
dbussink: if not, I'm not going to add it, just curious
14:39
<dkubb>
I personally am not going to make it easier to use an unstable PK :)
14:39
<dbussink>
dkubb: hehe, i think that can be really low priority :)
14:40
<dbussink>
dkubb: i never use anything but cascade or halt a delete when an fk is present
14:40
<dkubb>
yeah, because in most cases if you're doing it, it means you chose the wrong thing for your PK. one of the primary properties it should exhibit is stability
14:40
<dkubb>
dbussink: yeah me too
14:40
<dbussink>
last change to tsort was in 2006
14:40
<dkubb>
dbussink: tsort in ruby core?
14:43
<dkubb>
dbussink: are you worried that it might not be well maintained?
14:43
<dkubb>
the algo is fairly simple, and I should be able to verify it
14:43
<dbussink>
that would the main concern then yeah
14:43
<dkubb>
I found out earlier today that even bundler uses the same algo
14:43
<dkubb>
er the same lib
14:43
<dbussink>
it can mean that either it works well and doesn't need any changes, or nobody uses it
14:43
<dbussink>
ah, well, that already promises a lot more :)
14:43
<dkubb>
I usually view code as suspect if it's not been changed latelyl
14:44
<dkubb>
rarely is code perfect
14:44
<dkubb>
code that is changing is still "alive"
14:44
<dkubb>
they say that about speaking languages too.. if the language isn't still changing over the years, then it's probably declining in use and going extinct
14:45
<dkubb>
I think the same thing holds for programming languages, and software in general
14:47
<dkubb>
at mwrc, someone asked matz if he was going to put a moratorium on ruby language changes to give implementors time to catch up, and he said no
14:47
<dkubb>
which I think is a good thing, since it fits in with my theory that if something isn't changing then it's dying :)
14:47
<tonyc>
now if people would update their AWESOME CODE to work with ruby 1.9 we'd be set.
14:47
<tonyc>
i was porting an app to rails3 and decided to go with ruby 1.9 just for the hell of it.. too much useful shit is still broken in 1.9
14:48
<tonyc>
zentest, i'm looking at you
14:48
<dkubb>
tonyc: in the language or in libs?
14:48
<dkubb>
tonyc: ahh yeah, I can imagine
14:48
<tonyc>
i got sick of trying to track down whether something's been updated, and it's fucking frustrating.
14:48
<dbussink>
tonyc: dm should be up to date
14:48
<tonyc>
some libs haven't been touched in a couple years.
14:48
<tonyc>
yeah, i know, you're good at keeping things updated.
14:49
<tonyc>
but there are so many useful plugins or whatever that people put out there, but then don't maintain.
14:49
<dkubb>
I code in 1.9 now primarily
14:49
<tonyc>
or they don't say "uh this hasn't been used in a while"
14:49
<tonyc>
*cough* restful authentication
14:49
<dbussink>
tonyc: could that there are issue with encodings and DO though, probably a lot of edge cases not covered
14:49
<tonyc>
this is the one thing that turns me off from the ruby and rails community. people are too distracted at shiny things and don't think about people who are using their software.
14:50
<dkubb>
tonyc: yeah, if you look at alot of the hype in articles and whatnot, then I think that's right
14:50
<tonyc>
i'm not necessarily interested in using the latest bdd framework du-jour.
14:51
<tonyc>
you can get really far with test-unit, rails 2.3.x and autotest.
14:51
<dkubb>
tonyc: however, if you look at what people are using, then there's a different picture
14:51
<dkubb>
for example, if you were to believe the hype you'd think mongomapper is killing dm in usage
14:51
<tonyc>
the hype is what turns me off.
14:51
<dkubb>
but a simple search on rubygems shows we have much more usage
14:51
<tonyc>
and it's something honestly that I miss from my java days. shit was generally stable.
14:52
<dkubb>
I mean, those are total downloads, but even dm-core's last release was 16K downloads.. 8x more than MM has ever had combined
14:52
<dbussink>
tonyc: well, it's both the advantage and the achilles heel
14:53
<tonyc>
i found it very hard to keep up with merb, for example.
14:53
<dkubb>
there's alot of the "I'm going to fix some bugs in my library.. oh shiny" happening
14:53
<tonyc>
and then the merger got announced, so we bailed on merb and just rewrote the little we had in rails 2.3
14:54
<tonyc>
i really love how fast rails under 1.9 starts up. i just wish i could use the tools i'm familiar with.
14:54
<dbussink>
i see that dm is much more intertwined with our app, i could probably upgrade from merb to rails3 with relative ease
14:55
<dbussink>
so that's not a point i worry about a whole lot
14:55
<dkubb>
dbussink: yeah, most logic in an app lives in the models
14:55
<dkubb>
but it's funny how the focus is always on the framework
14:55
<dbussink>
dkubb: yeah, you've seen it :p
14:55
<dbussink>
the web framework you mean?
14:55
<dkubb>
dbussink: yeah, in your specific case I know.. but I'd say in the general case
14:55
<dkubb>
dbussink: yeah
14:56
<dbussink>
well, it's the part that you can quickly scaffold something with
14:56
<dbussink>
then the real work starts by creating actual logic
14:56
<dbussink>
not as shiny anymore then
14:56
<dkubb>
well written controllers tend to be thin, while the model and view are the tougher parts to refactor
14:57
<dbussink>
for me most important is that tools / frameworks don't bog you down
14:57
<dbussink>
but if that's above a certain threshold it doesn't matter too much anymore
14:59
<dbussink>
tonyc: you do see that there are certain projects that are maintained / mature
15:00
<dbussink>
try to use them as much as possible
15:03
<tonyc>
i thought autotest was at least maintained. i guess i'll have to re-evaluate that.
15:04
<tonyc>
for example, i never really picked up rspec, but at work we use test::unit and mocha.
15:04
<dkubb>
tonyc: zenspider and seattlerb were on fire a few years ago. not sure what's happened
15:04
<tonyc>
kind of reminds me of jamis' cap burnout
15:05
<tonyc>
at least some people cared enough to step up.
15:05
<dkubb>
dbussink: btw, tsort can be made stable
15:05
<dkubb>
tonyc: burnout happens to everyone. I know several people who are well known in the ruby community who have recently said they are close to burnout
15:05
<tonyc>
i burned out. heh
15:05
<dkubb>
tonyc: even a few months ago I was feeling the same way
15:06
<tonyc>
rails3 actually got me re-interested.
15:06
<dkubb>
what helped was having other stuff that wasn't related to programming, and starting up a few projects where I could learn something new
15:06
<tonyc>
at work, we're still on rails 2.2.2 and no real plans to do major upgrades, but we have companies like fedex on this code so we're a bit different.
15:06
<tonyc>
dkubb: i basically ignored programming for the past 9 months and got really into UX.
15:06
<tonyc>
went to the interaction 10 conference the other month.
15:06
<tonyc>
learned a ton of stuff.
15:07
<dkubb>
cool. the few books I've read about UX have been interesting
15:07
<dbussink>
i've done a workshop with adaptive path, was really nice to do
15:08
<dbussink>
and work with people from different backgrounds
15:08
<tonyc>
yeah, i have my own opinions about what the UX community needs to do. :)
15:08
<dkubb>
while I'm not usually on the front-end, I think it's important for everyone who does web apps to have some knowledge about
15:08
<tonyc>
the important thing is that ux isn't necessarily just about a pretty ui.
15:08
<dkubb>
just like how web developers should have some knowledge of HTTP
15:08
<dbussink>
i'm pretty good at ux, not very good at cool graphic design itself though
15:09
<dbussink>
tonyc: it can be radically different yeah
15:09
<dkubb>
often times a well designed UI is beautiful, but I think that's more of a side effect
15:09
<tonyc>
the whole flow of the app needs to be planned out.
15:09
<tonyc>
order of screens, minimizing excise, etc.
15:09
<tonyc>
anyway. yay for open source!
15:09
<dbussink>
what should be put where etc.
15:09
<dbussink>
putting things into context is really important
15:10
<dkubb>
tonyc: that stuff is also harder to change later, which is why I usually focus on that more than even internals in the beginning
15:10
<dbussink>
and allows for powerful yet still easy to use features
15:10
<dkubb>
even for API design I think it's important to think about these things
15:10
<dbussink>
i often start out with the user interface part of things
15:10
<dbussink>
and build some model underneath later on
15:10
<dkubb>
I mean, the UoW stuff in DM has been something I've been planning for almost 2 months.. talking about it all the time in the channel, and trying to figure out the best possible UI for it
15:11
<dkubb>
and the funny thing is that I am probably going to be the only person who uses the API (at least for now)
15:11
<dbussink>
working on a library is creating a ui in it's own way
15:11
<dkubb>
but if I ever do expose it to the public, I know it'll be solid
15:11
<dbussink>
and really important
15:11
<dkubb>
yeah, I think of an API as the programmer's UI
15:12
<tonyc>
good, because it is :)
15:12
<dkubb>
in the ruby world I think most people want a beautiful API too, which probably makes me focus on it more than I would if I was going it in perl or something where there are different qualities in idiomatic code
15:12
<dkubb>
idiomatic ruby should be beautiful
15:15
<tonyc>
railsapi.com would be AWESOME on an ipad.
15:15
<tonyc>
it's perfect.
15:15
<tonyc>
it's got the nice sidebar on the left.
16:03
<dkubb|away>
dbussink: for future reference, if you sort the nodes in tsort_each_node and tsort_each_child according to their insert order, you can ensure the sort is stable
21:22
<tonyc>
heh, anyone ever done a neo4j-dm-adapter yet?