search

jpoehls / dotnetmigrations

DotNetMigrations is a database migration framework that assists in managing and versioning database changes. It was originally designed as a straight port of the rails functionality located in the Ruby on Rails framework; however, has recently moved into a more open framework thanks to the power of the Managed Extensibility Framework.
Other
36 stars 10 forks source link

Discover connection strings in projects' web.config and/or app.config (Issue #19) #26

Open kieranbenton opened 12 years ago

kieranbenton commented 12 years ago

Hi James, Hope you're well and have had a nice Christmas and new years!

I've been trying to find some more time to devote to DNM, and this should hopefully be the first drop of many. Again, forgive my rustiness with Github and Git in general - I had to do some horrible things to get the pull request to just the single commit I wanted!

DNM now works pretty damn well with Nuget - its a very simple matter to add the package (I've only tried locally obviously) and then to just start adding migrations against connection strings you've already got set up. Any comments/code review welcome, I'm aware the connection "add/update/remove" commands may not function correctly in this configuration but wanted to see what you think first.

I'll still try and find some time to tidy those "combine" command commits up and get them to you - I still think this is valuable to have in the core feature set, our DBAs in particular would like to have a nice big script to run themselves come a production upgrade - even though we're using migrations internally! :)

Btw, did you know the TC build is down?

All the best, Kieran

jpoehls commented 12 years ago

Hey Kieran, thanks for this! I'll make time this week to review this further. It might be this weekend though. I also need to fix that TC build. Working on DNM is a lot less fun for me now because I work exclusively on my Mac at home now and hate booting into Windows. I'm grateful for your support though! I'll get it pulled in.

kieranbenton commented 12 years ago

Hi joshua! No problem. If there's anything I can do to help please let me know. Would getting dnm setup and working well under mono make life any easier for you?

I'd like to ask your advice about unit tests as well, I had a bash at putting some together for the patch I made, but wihtout a significant refactor across the board, I couldn't see an effective way of mocking the configuration. Any tips?

Cheers, Kieran

----- Original Message ----- From: Joshua Poehls [mailto:reply@reply.github.com] Sent: Tuesday, January 03, 2012 01:25 AM To: Kieran Benton me@kieranbenton.com Subject: Re: [dotnetmigrations] Discover connection strings in projects' web.config and/or app.config (Issue #19) (#26)

Hey Kieran, thanks for this! I'll make time this week to review this further. It might be this weekend though. I also need to fix that TC build. Working on DNM is a lot less fun for me now because I work exclusively on my Mac at home now and hate booting into Windows. I'm grateful for your support though! I'll get it pulled in.

Reply to this email directly or view it on GitHub: https://github.com/jpoehls/dotnetmigrations/pull/26#issuecomment-3335502

jpoehls commented 12 years ago

Mono support for DNM has been worked on before actually. It may in fact already work in Mono... I forget. Unfortunately though I'd still need to at least test in Windows and the bulk of DNM usage is SQL Server / SQL Compact so it isn't really feasable to soley develop it on Mono.

I'm pretty sure DNM code uses a ConfigrationWrapper class that is mockable. You should be able to find this in existing unit tests. However this may not work for what you are needing to test. I'll know more when I review your changes.

kieranbenton commented 12 years ago

Have you considered switching (or just mocking) to using SQLite? http://stackoverflow.com/questions/2644464/can-i-use-sql-server-compact-edition-ce-on-mono. That would let you run them on Linux too :) Again, I could help with that if you'd like.

I've pushed another commit that sorts some of the issues I had with ConfigurationWrapper out - and I've no longer had to resort to horrible static methods so that’s nice :)

Yes I've seen the tests for the LogRepository, but as you mentioned I'm struggling (quite new to TDD in general) as to how I can mock something whose behaviour is reliant on if there are files on disk or not (especially given that "System.Configuration.ConfigurationManager" isn't easily mockable itself). Any advice would be great and I can get those added :)

Something else I wanted to ask you about... I would like to build some "example" code that the Nuget package could include in the host application to run the "version" & "migrate" command on startup from migrations held either on disk or in resources - basically making an application self updating. However, I've realised all of the commands exist within the "db.exe" assembly itself and not in DNM.Core.

Do you have any objections if I move them into there, and make db.exe itself much more of a stub?

Cheers, Kieran

-----Original Message----- From: Joshua Poehls [mailto:reply@reply.github.com] Sent: 03 January 2012 18:57 To: Kieran Benton Subject: Re: [dotnetmigrations] Discover connection strings in projects' web.config and/or app.config (Issue #19) (#26)

Mono support for DNM has been worked on before actually. It may in fact already work in Mono... I forget. Unfortunately though I'd still need to at least test in Windows and the bulk of DNM usage is SQL Server / SQL Compact so it isn't really feasable to soley develop it on Mono.

I'm pretty sure DNM code uses a ConfigrationWrapper class that is mockable. You should be able to find this in existing unit tests. However this may not work for what you are needing to test. I'll know more when I review your changes.

Reply to this email directly or view it on GitHub: https://github.com/jpoehls/dotnetmigrations/pull/26#issuecomment-3344326

jpoehls commented 12 years ago

I've considered switching to Sqlite for the unit tests before, I think I may have even done it at one point but maybe that was on another project. I may have to give that another shot and see if I can go completely Mono and depend on others, like you to test the Windows side. ;)

Your suggestion of self-updating apps is ABSOLUTELY on my roadmap for DNM. This is something I've wanted to enable for a long time now.

Hold off moving the commands for now. I would rather implement a more friendly API for this. The commands are very much built strictly for command line access and wouldn't be nice to use from code.

kieranbenton commented 12 years ago

Ok will do. I think you'll have trouble with the build scripts being powershell based as well won't you? Again, please shout if I can help - I've got a fair bit of experience with using msbuild (which I believe is compatible with xbuild on mono?) which we could use.

Ok, np. I'm going to hold off on adding powershell commands too as the best I'd be able to do at the moment is just a redirect to the db.exe tool. Not very classy and wouldn't fit powershell at all. Would be better to have Dnm-Migrate or something. Consider renaming db.exe to dnm.exe as well? It differentiates itself a bit then.

Cheers, Kieran

-----Original Message----- From: Joshua Poehls [mailto:reply@reply.github.com] Sent: 06 January 2012 15:51 To: Kieran Benton Subject: Re: [dotnetmigrations] Discover connection strings in projects' web.config and/or app.config (Issue #19) (#26)

I've considered switching to Sqlite for the unit tests before, I think I may have even done it at one point but maybe that was on another project. I may have to give that another shot and see if I can go completely Mono and depend on others, like you to test the Windows side. ;)

Your suggestion of self-updating apps is ABSOLUTELY on my roadmap for DNM. This is something I've wanted to enable for a long time now.

Hold off moving the commands for now. I would rather implement a more friendly API for this. The commands are very much built strictly for command line access and wouldn't be nice to use from code.

Reply to this email directly or view it on GitHub: https://github.com/jpoehls/dotnetmigrations/pull/26#issuecomment-3386194

jpoehls commented 12 years ago

Gah. I forgot about the PS build. I've used msbuild before but hate the XML. Um, Ruby! ;)

kieranbenton commented 12 years ago

Lol, and it’s a that point you've lost me :) I've been meaning to try it... but never quite made it!

Msbuild does love its XML, I blame Ant - its actually not so bad once you get going though, you just have to stop thinking procedurally! :)

-----Original Message----- From: Joshua Poehls [mailto:reply@reply.github.com] Sent: 06 January 2012 16:56 To: Kieran Benton Subject: Re: [dotnetmigrations] Discover connection strings in projects' web.config and/or app.config (Issue #19) (#26)

Gah. I forgot about the PS build. I've used msbuild before but hate the XML. Um, Ruby! ;)

Reply to this email directly or view it on GitHub: https://github.com/jpoehls/dotnetmigrations/pull/26#issuecomment-3387222

kieranbenton commented 12 years ago

Hi Josh, Don't suppose you've had time to look at this yet have you?

I've been looking at switching to sqllite for the tests and I'm not far off of a patch that will do both. Whats your preference in terms of which tests to run when on which platform? Obviously duplicating all the existing tests is a waste - so I'm looking for a bit of advice.

Cheers.

-----Original Message----- From: Joshua Poehls [mailto:reply@reply.github.com] Sent: 06 January 2012 16:56 To: Kieran Benton Subject: Re: [dotnetmigrations] Discover connection strings in projects' web.config and/or app.config (Issue #19) (#26)

Gah. I forgot about the PS build. I've used msbuild before but hate the XML. Um, Ruby! ;)

Reply to this email directly or view it on GitHub: https://github.com/jpoehls/dotnetmigrations/pull/26#issuecomment-3387222