I've read some posts about the use of SQLCE in Umbraco. I'd particularly noted problems with umbraco inexplicably 'losing' data for no apparent reason.
I would like to use SQLCE in our next project in development so that I can check-in an entire build into our source control. By keeping the database side of things nice and simple we can source control Umbraco (versions) during the shared developement process. Deployment to our staging/test & production server will use SQL server web edition rather than CE.
I'll keep the databases in-sync between developers by using uSync as it seems pretty stable in u7 and we can share the XML it generates as part of our check-ins. Much as it pains me to use Courier, we will employ it's use to copy down selected content and media from our staging server to our dev builds as required.
Well thats the thought process, so SQLCE or not? Can anyone comment on whether it's a go? Or should I leave it well alone?
I should add, my assumption is build 41 (Courier 2.7.8) will actually work in Umbraco 7! It would appear at least to be the case in the nightlies....But I've yet to validate this! :-)
I'm interested in wether when you migrate from SQLCE to SQL Server if your DB at the end has the full Umbraco db structure. I'd imagine you'd be missing some indexes and the like. Can anyone confirm?
It would never be the intention to migrate one build to another as i've done so often before. This would mean on any given build it need not matter what database system is in use.
The approach described in my first post would be a seperation of concerns within my project. So anything thats changeable, CSS, JS, Razor etc will be source controlled in the way i've always approached it before. The difference being I can rely on uSync to shell out my doctypes, macro entries, template entries etc to the filesystem which can be checked in along with my code. Basically all developer orientated 'non content' thats stored in the DB normally.
If a developer wants to access content in their "empty" dev build they can use Courier 2 to pull down content from the staging server or possibly even the production server.
It's important to note I dont personally consider Courier 2 to be a stable product so it would only ever be available to devs to use!
I think I get the way you're thinking...but I'm not sure the approach is right.
In my company we have a devDatabase (MSSQL), which we share among our local machines and our staging environment.
I think that it's better since keeping your CE SQL database up to date can be a pain if you're going to track it in your source control. You should also be aware that not all packages support CE SQL. The Url tracker for instance does not support it and neither does Contour - at least not if you need to migrate from the CE SQL to MSSQL for instance...then you'll see a lot of errors.
So even though you could use usync or umport to keep the CE SQL database up to date I think things can perhaps get a bit messy.
hmm really? I wasnt aware of any packages being database engine dependent? But I guess it's down to the use of features absent from SQLCE like stored procedures, views etc.
I suppose for the sake of compatibility it would be better to use SQLExpress. I'm assuming I can shove the MDF in App_Data and use the following ConnectionString?
If so, I can still check it in with my build. It will be a v7 initialised "empty" database containing all of the necessary tables. uSync and a post build script will do everything else required.
There isn't a need to keep content in-sync between developers, but Courier 2 will be there to pull stuff down from staging/production without having to manually recreate stuff.
LOL, I've suffered plenty of tears over the years, but we stick with Umbraco because its so darn flexible and it keeps development in-house too. :-)
Looking at this more carefully I can see where you're coming from....
As far as I'm concerned the "umbraco build" is literally only meant to be our starting point, combining the SQL Express v7 initialised database too. So, post installer, with an empty site setup. A TFS stored set of uSync files will provide all the structure along with all the other necessary web dev files.
What I'll do is source control each "base" build in a TFS folder which i'll call "Umbraco CMS". I'll create a new website project here every time Umbraco increments a version I think is worth, or forced to implement. So I guess not really much different from doing a pull from nuget but with the application initialised.
I've decided to re-think things a little because I'm getting pretty sick of doing hugely complicated merges when we upgrade an Umbraco version. Hopefully this way I can make it little less annoying, with a view to build automation in the future too. Each time we move up a version the build scripts will have to be updated to reflect the newest base build in TFS.
Using SQLCE in Umbraco 7
I've read some posts about the use of SQLCE in Umbraco. I'd particularly noted problems with umbraco inexplicably 'losing' data for no apparent reason.
I would like to use SQLCE in our next project in development so that I can check-in an entire build into our source control. By keeping the database side of things nice and simple we can source control Umbraco (versions) during the shared developement process. Deployment to our staging/test & production server will use SQL server web edition rather than CE.
I'll keep the databases in-sync between developers by using uSync as it seems pretty stable in u7 and we can share the XML it generates as part of our check-ins. Much as it pains me to use Courier, we will employ it's use to copy down selected content and media from our staging server to our dev builds as required.
Well thats the thought process, so SQLCE or not? Can anyone comment on whether it's a go? Or should I leave it well alone?
Thanks in advance
Martin
I should add, my assumption is build 41 (Courier 2.7.8) will actually work in Umbraco 7! It would appear at least to be the case in the nightlies....But I've yet to validate this! :-)
M.
I'm interested in wether when you migrate from SQLCE to SQL Server if your DB at the end has the full Umbraco db structure. I'd imagine you'd be missing some indexes and the like. Can anyone confirm?
Hi Steve
It would never be the intention to migrate one build to another as i've done so often before. This would mean on any given build it need not matter what database system is in use.
The approach described in my first post would be a seperation of concerns within my project. So anything thats changeable, CSS, JS, Razor etc will be source controlled in the way i've always approached it before. The difference being I can rely on uSync to shell out my doctypes, macro entries, template entries etc to the filesystem which can be checked in along with my code. Basically all developer orientated 'non content' thats stored in the DB normally.
If a developer wants to access content in their "empty" dev build they can use Courier 2 to pull down content from the staging server or possibly even the production server.
It's important to note I dont personally consider Courier 2 to be a stable product so it would only ever be available to devs to use!
M.
Hi Martin
I think I get the way you're thinking...but I'm not sure the approach is right.
In my company we have a devDatabase (MSSQL), which we share among our local machines and our staging environment.
I think that it's better since keeping your CE SQL database up to date can be a pain if you're going to track it in your source control. You should also be aware that not all packages support CE SQL. The Url tracker for instance does not support it and neither does Contour - at least not if you need to migrate from the CE SQL to MSSQL for instance...then you'll see a lot of errors.
So even though you could use usync or umport to keep the CE SQL database up to date I think things can perhaps get a bit messy.
Hope this input helps.
/Jan
Hi Jan
hmm really? I wasnt aware of any packages being database engine dependent? But I guess it's down to the use of features absent from SQLCE like stored procedures, views etc.
I suppose for the sake of compatibility it would be better to use SQLExpress. I'm assuming I can shove the MDF in App_Data and use the following ConnectionString?
If so, I can still check it in with my build. It will be a v7 initialised "empty" database containing all of the necessary tables. uSync and a post build script will do everything else required.
There isn't a need to keep content in-sync between developers, but Courier 2 will be there to pull stuff down from staging/production without having to manually recreate stuff.
M.
Hi Martin
Yup, tried these two scenarios myself...and I kinda cried you know...So I'll spare you the tears ;-)
Hmm, perhaps you could do it like that...I'm not sure but would love to hear if it works out.
Cheers, Jan
Hi Jan
LOL, I've suffered plenty of tears over the years, but we stick with Umbraco because its so darn flexible and it keeps development in-house too. :-)
Looking at this more carefully I can see where you're coming from....
As far as I'm concerned the "umbraco build" is literally only meant to be our starting point, combining the SQL Express v7 initialised database too. So, post installer, with an empty site setup. A TFS stored set of uSync files will provide all the structure along with all the other necessary web dev files.
What I'll do is source control each "base" build in a TFS folder which i'll call "Umbraco CMS". I'll create a new website project here every time Umbraco increments a version I think is worth, or forced to implement. So I guess not really much different from doing a pull from nuget but with the application initialised.
I've decided to re-think things a little because I'm getting pretty sick of doing hugely complicated merges when we upgrade an Umbraco version. Hopefully this way I can make it little less annoying, with a view to build automation in the future too. Each time we move up a version the build scripts will have to be updated to reflect the newest base build in TFS.
I'll let you know how it goes.
M.
.
is working on a reply...