04:16 <somebee_> hmm, associations in next seems extreeemely buggy right now. I'm encountering 3 different showstoppers trying to implement some relatively simple business-logic

13:13 <somebee> dkubb: http://datamapper.lighthouseapp.com/projects/20609/tickets/846-deleting-self-referential-1m-collection-destroys-_every_-resource-of-model#ticket-846-1 fyi, managed to recreate the other bug I talked about yesterday

13:16 <dkubb> somebee: hey

13:16 <dkubb> somebee: awesome, I will look at it shortly

13:16 <somebee> dkubb: hey. hate to bring you 'bad news' all the time, dont stress it :)

13:16 <dkubb> somebee: sorry I couldn't look at it sooner. RailsConf is great for socializing and getting stuff planned, but not so great for hacking on really tough problems

13:17 <dkubb> somebee: no, by all means, I love getting those bug reports

13:17 <somebee> dkubb: not sure if its the sel-branch or not, but I've stumbled upon several showstopping problems with associations.. it feels as if its the same underlying problem in all the cases though, which is probably a good thing

13:18 <dkubb> somebee: that's good. relationships are pretty consistent now, so if there are bugs that apply to more than one it's likely a fix in relationship.rb is all I'd need to do

13:19 <somebee> dkubb: should I file the other bug in lighthouse to? the gist from yesterday.. probably good to have it all in one place

13:19 <dkubb> somebee: yeah, if you can file a bug for that too. it helps me keep all the details organized

20:38 <dkubb> dbussink: did you see this post by Aaron Patterson: http://tenderlovemaking.com/2009/05/07/fat-binary-gems-make-the-rockin-world-go-round/

21:31 <snusnu> dkubb: http://github.com/bmabey/database_cleaner/tree/master now has full datamapper support (ben mabey pulled my changes in) .. no excuses for not using datamapper in a cucumber/webrat/selenium setup (i.e. in a setup where transactional fixtures are not possible)

21:32 <snusnu> dkubb: btw .. what do you think about http://sick.snusnu.info/2009/05/07/datamapper-storage-engine-reflection/ ?

21:56 <dkubb> snusnu: sweet! although I should check one project I worked on, where I think I got transactions to work with a cucumber setup

21:57 <snusnu> dkubb: from what i heard it's not cucumber making problems .. but selenium (which runs in a different process) .. don't quote me on that .. i dunno why that would be a problem .. but i think i heard people say that

21:58 <dkubb> snusnu: oh, right. I haven't use selenium with webrat yet. do you like it?

22:01 <snusnu> dkubb: hmm .. i only started using it a few days ago .. it sometimes feels a bit brittle ... timing issues i suppose ... we are using loads of javascript in our app, and sometimes i have the feeling that it operates either too fast or too slow ... could be me still using it wrong, though

22:04 <dkubb> snusnu: it still feels like that side of things isn't fully mature yet, but I'm not an expert or anything. we still need people to use it tho, because that's what pushes things forward

22:07 <snusnu> dkubb: true, the main issue here, i think, is that browsers have no unified callback api for their dom manipulations ... that's why selenium and the likes seem to only wait an appropriate amount of time, before they check something, not much more they can do .. at least not crossbrowserish

22:07 <snusnu> could be wrong here though

22:14 <snusnu> dkubb: do you think packaging support for truncate in a separate dm(more) plugin makes sense?

22:15 <dkubb> snusnu: you mean the TRUNCATE <table> command?

22:15 <dkubb> *sql command

22:15 <snusnu> yep

22:19 <snusnu> dkubb: actually it's no big deal to issue it directly on the adapter .. but only for db's that have it available as TRUNCATE ... sqlite and postgres do it differently (more work to do) .. and also there's this issue with referential integrity

22:20 <snusnu> dkubb: have a look at http://is.gd/xVPJ ... there's the code for truncation ... and also, the code for efficient listing of all tables in the database!

22:21 <snusnu> dkubb: so there are 3 things .. truncation .. finding all available tables (storage_names) ... and the storage engine reflection thing from http://sick.snusnu.info/2009/05/07/datamapper-storage-engine-reflection/

22:22 <dkubb> snusnu: just curious, have you tested your system when dm-constraints is turned on?

22:23 <dkubb> snusnu: I find that to be a good test to see if you've got the deletion logic solid

22:23 <snusnu> dkubb: good point .. let me try that! (there is still this issue with dm-constraint desperately needing the :constraint option explicitly specified ... and bailing out if it isn't ...

22:45 <dkubb> snusnu: I thought about doing something in DataObjects so that when you did a DELETE without a WHERE clause, it would just use TRUNCATE, but I have to research the differences.. I don't remember if there were any caveats

22:46 <snusnu> dkubb: from what i heard, one difference is that truncate resets the ids to start with zero? don't know if that's true .. and i don't know if it does so on every db

22:47 <snusnu> dkubb: i think i remember one guy just a week or so ago, who said he wants to use truncate because he needs the ids to start with zero

22:47 <dkubb> snusnu: ahh, that's interesting. what about just dropping and recreating the DB instead of truncate? which is faster do you think?

22:47 <dkubb> er, recreating the table I mean

22:47 <snusnu> dkubb: because he was doing some large importing ... where he needed to rely on consistent ids

22:48 <snusnu> dkubb: yeah, i remembered saying the same to him ... unfortunately i don't remember his answer :(

22:49 <snusnu> dkubb: i don't really see a difference .. both scenarios would need referential integrity checks to be turned off anyway ... so it shouldn't matter probably?

22:50 <dkubb> snusnu: unless there's something I'm missing, I think drop table/create table would beat DELETE in terms of speed. I would also bet TRUNCATE does a drop/create under the hood anyway

22:53 <snusnu> dkubb: totally guessing here ... what happens to triggers, or any other metadata that's possibly connected with the table in question?

22:53 <* snusnu> is not very familiar with advanced rdbms concepts ...

22:54 <dkubb> snusnu: that's a good question. if the triggers or other constraints were added during auto-migrate by a properly written DM plugin, then they should be recreated with the table

22:54 <dkubb> snusnu: however, if you added them manually I think TRUNCATE might be the only safe way to persist that state

22:54 <snusnu> dkubb: true

23:08 <snusnu> dkubb: just tested truncate with referential integrity .. works fine (by disabling referential integrity before truncation, and reenabling it afterwards) .. or more exactly .. setting it back to the state it was before truncation

23:08 <snusnu> (on mysql that is)

23:09 <snusnu> dkubb: i basically copied/adapted all this stuff (especially the sql queries) from activerecord

23:10 <snusnu> dkubb: for sqlite3, mysql and postgres

23:10 <snusnu> dkubb: the statements are identical to the ones activerecord uses