Support an easy way to populate data from a Migration (Fixtures)

[GoogleCodeExporter]

Yet another enhancement request.  It would be cool if there was an easy way
to populate newly created tables with data (for testing, or for lookup
tables, etc).  Right now we could do it with lots of insert statements in
the Migration, but it would be very handy to have something like Ruby's yml
fixture files (or maybe something more structured, like XML?).  

I'm going to spend some time thinking about how to implement this (how does
Migrator know where to find the data files, should they be embedded in the
migration DLL, make sure branches and merges don't break the approach, etc)
but if anyone has any ideas I'd love to collaborate on design before I
start trying to code it.

Original issue reported on code.google.com by evon...@gmail.com on 1 Aug 2008 at 1:21

[GoogleCodeExporter]

Could be csv (first row is column names, subsequent rows are data to insert)?
YML maybe, but that fits better with an ORM model.

Maybe just a better interface for inserts?

Original comment by geoffl...@gmail.com on 5 Aug 2008 at 10:16

• Changed state: Accepted
• Added labels: Milestone-9, Type-Enhancement, Usability
• Removed labels: Type-Defect

[GoogleCodeExporter]

Don't know if this helps, but I do this via a test project.  I have fixtures 
that
have RoR-like names so I can create them and have a single big test that will 
create
them all.  It doesn't work well for static stuff like lookups, but for 
populating the
demo and test data, it's great.  To get to this, I used PLINQO (but you could 
also
use LINQ to SQL or LINQ to Entities, depending on your data model).  Then you 
can run
the test project to populate all the data.

Another suggestion would be to have custom code that runs in the AfterUp 
method.  You
could have methods that populate the data based on the current table as of that
migration.  It's a little messy, though since the data has to reflect the state 
as of
that migration.  I don't really like the idea of doing it with straight inserts
(unless it is lookup data), since it's going to be hard to keep everything 
lined up.
 If you are willing to create an entity project that does nothing but get used to
create entities that you can use in a test project, I think you can get where 
you
want and still add value via testing.

Original comment by spencer....@gmail.com on 2 Sep 2008 at 6:05

[GoogleCodeExporter]

I have had this requirement in my project, I am using quite an old version of 
Migrator (huh, I am apparently a maintainer...), and I think the refactorings 
may 
have lost what I am talking about.

Basically I use Castle.ActiveRecord to take care of inserting the data. This 
seems to 
be the cleanest & easiest option to support IMHO, as (most) of the database 
issues 
are taken care of by activerecord (or i guess you could use LINQ, or whatever 
is your 
DAL). The issues I ran across had to do with initializing activerecord 
(ActiveRecordStarter.Initialize()), which had to be done from within the 
assembly 
that was accessing the database using ActiveRecord, and passing in the 
xmlConfig. It 
was a little bit messy, but works.

I also have found with importing data using csv data, that this does not work 
well 
with updating the csv data. If I import the data in a migration, and then 
update the 
csv file, the new data will not get inserted, as it is in an old migration. 
Inserting 
directly via activerecord takes care of this problem, new data being inserted 
with a 
new migration.

Just my $0.02. Let me know if you want any more details.

Original comment by nick.h...@gmail.com on 4 Sep 2008 at 10:45

[GoogleCodeExporter]

One thing I would suggest thinking about is having an option to _not_ run / 
generate
the test data into sql.  This helps when you go to deploy your changes to 
production,
and you don't want to insert test data for testing purposes.  This could be 
done by
adding something simple like '.Tests' to the namespace of each test class. 

Original comment by tommy....@gmail.com on 29 May 2009 at 11:02