|macographer||well, the breakpointer doesn't work. maybe 'breakpoint' will still stop your app, but i guess you can't run the breakpointer to intercept it.|
|versix||it;s really useful|
i think so too. although, i've heard people say otherwise.
well, not 'otherwise' per se, but at least something along the lines of "you're doing something wrong if you're relying on breakpointer"
but i never heard an explanation, so i say, screw it.
|versix||yes... I have heard that too in relation to debuggers in general|
|macographer||i guess there is some sort of alternative|
but i haven't looked into it, because i didn't need it.
|omninerd||can anyone recommend a good stats/report app for svn?|
|macographer||omninerd: did you ask in #svn?|
|omninerd||no :-) ... just curious if the Rails crew had any favorites (perhaps that might play well with Rails)|
|macographer||ah, just checking. you never know if someone knows about it, or if they have a specific reason for asking here.|
it's pretty slow right now.
|thoraxe||man i hate databsaes with columns in tables out of order|
but i guess it doesn't really matter with rails
since you're never supposed to look at the db anyway
you can generate a migration to put data into the DB
but is there any way to somehow dump the data FROM the DB into some kind of migration?
erm, wrong window
|omninerd||thoraxe ... you mean for repetative loads?|
i'm about to start adding columns to databases
i'm still in development but i've got a bunch of data in the db tables for testing purposes
and on the odd chance that I accidentally screw something up i'd rather not have to re-enter it
so it'd be nice if I could create some kind of migration that's essentially a snapshot of the current DB data
|omninerd||why don't you dump the db for backup and then migrate it? there should be no data loss|
|dwilkins||thoraxe: mysqldump will do that nicely.|
dwilkins: mysqldump will give me a dump of the data, but no rails way to put it back in
|omninerd||mysqldump (assuming you're using mysql)|
|thoraxe||i'd have to know the schema version right now so that i could rake back and then reinsert the data|
not that that's unacceptable
|omninerd||use your current db as sqaure 1 ... then build on it with migrations|
|thoraxe||the current db was built with migrations to where it is|
then data was added
|versix||and isn't the current schema version stored in the db anyway?|