This project is read-only.

Storing information in a different database

Topics: Writing modules
Jun 24, 2011 at 6:04 PM

From everything I've read, Orchard makes it very easy to store information in its own database. But we need to integrate Orchard with a fairly complex pre-existing backend (consisting of a home-grown repository + EF + SQL Server).

This is a rather different scenario than the existing documentation and code samples presume, and I'm still wrapping my head around Orchard, so I could use a little guidance on best practices in this regard.

Should we just create a standard MVC app and ignore the Orchard plumbing entirely, other than decorating our controllers with a [Themed] attribute? I'm pretty sure I can make this work, but I suspect I'd be giving up some useful functionality - though I'm not sure exactly what.

Should we use the Orchard plumbing as much as humanly possible, and only override the piece(s) that actually persist things to the database? (Not sure what pieces these are - for all its talk about simplicity, Orchard is astonishingly complex.)

Should we do something somewhere in-between?

I surely can't be the only person who's trying to do this. Are there any blog posts/code samples on best practices in this regard?

Jun 24, 2011 at 7:51 PM

How much you integrate with Orchard is your choice. It really depends if your legacy content would gain from being exposed as parts into custom content types.

Jun 25, 2011 at 12:45 AM

I'm wrestling with this too. I'm trying to wrap my mind around having my site configuration stored alongside my content, in the same database. I also get nervous that the database is a flat file right amongst my site's code. It seems likely that I will accidentally re-deploy my site from a local copy and wipe out all my live data. It's a little better when using a separate SQL Server Express or SQL Azure database, but that adds other complexities

Jun 25, 2011 at 12:55 AM

A flat file? uh? There is nothing flat about this file. I don't understand: you are complaining about the database being a file in the site, but you also complain about "other complexities" associated with using SQL Server. I don't see how you can possibly be satisfied ;)

Jun 27, 2011 at 9:03 PM
Edited Jun 27, 2011 at 9:03 PM

Yeah, I agree that a SQL Server Compact database file is not very flat. :) I guess what I was thinking is that when using SQL Server Compact in Orchard, your site configuration, user data and content are all in the same database file. I like to develop my site on a local box, then publish changes to my live server. As it is, if I make changes to my local site's configuration, there's not an easy way to roll those changes to my live site without also wiping out my live content and user data. Since it's all in the same database file, it would overwrite all of my live data with my local development data. I was thinking that it might be nice to have site configuration data in a separate database than the user data and content. Is this correct thinking? Maybe I'm just doing it the wrong way.

Jun 27, 2011 at 9:06 PM

Ah, well, deployment of content is a different problem, that I hope we can tackle in 2.0. In the meantime, Export/Import can give you a good way to deploy only part of the content. Did you try that already?

Jun 28, 2011 at 12:32 AM

Using Import/Export is a great idea. I actually haven't tried that yet. So, let me see if I understand your suggestion. I can make structural changes to a local copy of my site such as adding modules, configuring modules/features, and modifying core settings. Then, when it's time to deploy the changes to my live site, rather than upload my local files I can do an Export of the local site and then import that recipe(?) file into the live site. Is that correct? I assume that will leave my customer data and content alone and only modify configuration data. If so that's a great solution.

Jun 28, 2011 at 12:51 AM

Yes, provided you apply common sense and do backups and test the procedure, that is correct.