tag:blogger.com,1999:blog-11933937.post744880096818773440..comments2008-03-29T17:34:34.055-05:00Stephen Chuhttp://www.blogger.com/profile/07181510921622947661noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-11933937.post-85320300237316513672008-03-29T17:34:00.000-05:002008-03-29T17:34:00.000-05:00Actually, I ended up figuring it out. Turns out the testing framework of Rails includes a class to handle testing file uploads. So I just grab that and I'm good to go! It's quite cool as I can keep images in a reference_data/images directory and then do stuff like this:<BR/><BR/><B><BR/>require 'action_controller/test_process'<BR/><BR/>Logo.create! :uploaded_data => ActionController::TestUploadedFile.new(<BR/>'test/reference_data/images/logo.jpg', <BR/>'image/jpg')<BR/></B><BR/><BR/>So now I can load images through attachment_fu and it does all the resizing, thumbnailing, directory creation and such.<BR/><BR/>I ended up creating a custom rake task to delete the images store (the attachment_fu processed images, not the ones in reference_data!), wipe the DB, recreate it, run the migrations and load my data (via your idea).<BR/><BR/>So voila! single command and I'm ready to go!<BR/><BR/>Thanks a million!<BR/><BR/>-DanDanimalhttp://www.blogger.com/profile/11574843756882461141noreply@blogger.comtag:blogger.com,1999:blog-11933937.post-2564802257422959922008-03-29T14:07:00.000-05:002008-03-29T14:07:00.000-05:00Stephen,<BR/><BR/>I love this idea but I'm wondering how you'd handle prepopulating binary data? I.e. I use attachment_fu for logos for some models. I can see having a "reference_images" directory to hold the source files for the logos. But I don't know how to simulate the data read that happens from a form using a file_field<BR/><BR/>Thoughts?Danimalhttp://www.blogger.com/profile/11574843756882461141noreply@blogger.comtag:blogger.com,1999:blog-11933937.post-46502854930371914602007-12-21T03:02:00.000-06:002007-12-21T03:02:00.000-06:00Hello,<BR/><BR/>I'm quite new in Ruby so I don't know that much about it. <BR/>What you describe is very useful for me but I need more details. From your example it seems that you only get the data from a table imported and exported into the new structure of the database, is this correct?<BR/>Is it possible to have more examples and tutorials on Rubby??<BR/><BR/>Regards,<BR/>Pedro<BR/>pedro_garrinhas@hotmail.comAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-11933937.post-60980642762375540082007-12-18T00:24:00.000-06:002007-12-18T00:24:00.000-06:00Curtis:<BR/><BR/>First, thank you for sharing your thoughts. I love it when I get honest feedback :-)<BR/><BR/>Just to clarify, the strategy above is deduced from experiences of a 16-developer Rails project. It works out quite well for us.<BR/><BR/>Both <B>reference data</B> and <B>user data</B> that I mentioned above are all data <I>required</I> for the application to go into production. If, while developing a feature, you have <I>temporary</I> data that you are unwilling to blow away, one can solve this problem by having a third set of data (perhaps called <I>development data</I>) and be loaded in your <I>data:load</I> after <I>:reference_data</I> and <I>:user_data</I>. My advise is, script them. It shouldn't be too hard to script such data, or it indicates to me the model/controller is hairy and needs some refactoring love. After you are done with your feature, your development data hopefully either becomes legit reference data or user data, or becomes part of another dataset's (like QA/Testing) reference data or user data. I would still advise such data to be part of one of your development datasets. The fact that you can selectively load any datasets for any environments by not using migrations gives you a lot more control over your data on what gets loaded and what doesn't.<BR/><BR/>Don't hate blowing away your database during development. Because, it happens, and I do it on every check-in. The point is, find ways to re-generate all your data using ActiveRecord models, and keep all data valid *at all times*. If you have data in your database you cannot generate through AR models because it violates validations, you will want to blow away your database.<BR/><BR/>Collapsing migrations is a good and efficient way to reduce the number of migrations. But IMHO I don't need to use this trick yet when I don't even need migrations.<BR/><BR/>Once your application goes into production, not just database migrations but the whole development becomes quite a different ball game. Release 2.0, bug fixes, app monitoring, testing, branching, etc., all become important at a different level. But, since you need them all once you go into production, does it make sense to do them all in pre-release 1.0 just to get some training? From 1.0 and on, <I>'planning'</I> becomes the name of the game before your every move.Stephen Chuhttp://www.blogger.com/profile/07181510921622947661noreply@blogger.comtag:blogger.com,1999:blog-11933937.post-29214433269107935732007-12-17T11:43:00.000-06:002007-12-17T11:43:00.000-06:00Stephen,<BR/><BR/>I personally have found it a joy to use migrations during development for teams larger than one. As soon as you have more than one developer, you have the potential to step on each other's toes.<BR/><BR/>If I'm working on a feature, putting in and taking out data as I develop, I hate having to blow away my database when developer #2 adds a column to a table. This data may not be reference data or even required--it's just data that I'm working with at that very moment, and I want it to stick around until I'm finished with it.<BR/><BR/>If migrations get big and messy, then we'll collapse and clean them up before we roll to production, but I still like having them during development. And, shoot, if we're going to use migrations as soon as we roll to production, we might as well train ourselves well with them during development.<BR/><BR/>Having the reference data as a rake task is a cool idea, though.Curtis Summersnoreply@blogger.com