SQL Server Compact Edition - Technical Implications

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
1/11/2010 10:29:47 AM
retroviz
Gravatar
Total Posts 72
View Posts

SQL Server Compact Edition - Technical Implications

Hi (again),

I have a project where I need to provide an "offline" portal site. Naturally (since SharePoint just makes this too damn hard) I want to use mojoPortal.

Can you see any technical implications of using SQL Server Compact Edition to run mojoPortal?

Ideally I would like to have the live mojoPortal site running within our domain and then use the Microsoft Sync Framework to sync down changes / updates to mojoPortal. Obviously this could be physical files and database changes.

Thanks,

Ben

1/13/2010 6:41:04 AM
Joe Audette
Gravatar
Total Posts 18439
View Posts

Re: SQL Server Compact Edition - Technical Implications

SQL CE does not support Stored Procedures therefore our existing SQL data layers will not work with it. (There may be other barriers as well). It would require creating and maintaining a data layer specifically for SQL CE. It would certainly be a big job to make an initial implementation and a long term commitment to maintain it. It is not something that I would want to implement or maintain.

SQLite is a file based db that could work well for offline, but how you would sync it with a server running MS SQL or any server db for that matter is not something I know of a solution for.

Best,

Joe

1/13/2010 9:28:57 AM
Joe Davis
Gravatar
Total Posts 2239
View Posts

Re: SQL Server Compact Edition - Technical Implications

Ben,

Why don't you use SQL Server Express?

-Joe D.

1/13/2010 4:33:13 PM
retroviz
Gravatar
Total Posts 72
View Posts

Re: SQL Server Compact Edition - Technical Implications

Joe (A), thanks for the suggestion. I think we will probably look to use something like SQLite and then write a sync feature to sync back with the central site.

Joe D, reason for wanting compact edition was partly due to the low footprint of compact edition but mainly due to the Microsoft Sync Framework providing a very easy means of synchronizing a SQL Server DB with an "offline" compact edition db.

It's true we could use SQL Server Express but we want the smallest possible footprint so I think Joe's suggestion of SQLite may be the best option.

Thanks

Ben

1/18/2010 7:27:25 AM
retroviz
Gravatar
Total Posts 72
View Posts

Re: SQL Server Compact Edition - Technical Implications

Hi Joe,

Could do with your thoughts on this.

So the aim is to have one *live* parent site whose content is downloaded to client sites. It should be database independent as I would probably have the publishing site running on SQL Server and child sites running on SQLite.

What I would like to do is build a feature like publishing sites in SharePoint.

My idea would be that features can implement IPublishable and that an individual site can be enabled as a Publishing Site.

Additionally a site will have an option to retrieve content from a publishing site (specifying the publishing site's URL).

I'm thinking the best way of publishing the content is via web services and retrieving the content using the built in scheduled task framework.

Pages would need to be synchronized separately and there would need to be a number of events for each e.g. PostFeatureContentAdded and FeatureContentAdded.

This is because some features may require some additional processing. For example, the Shared Files module will need to ensure than in addition to the database records being written, the files are also downloaded.

In addition you may want to do some PostFeatureContentAdded logic like translating the content. This would be quite a good way of deploying multilingual sites.

Of course I am not asking you to build such features but would like your opinion on feasibility and value to the project. The main thing is that it needs to be something that can be enabled on specific modules without altering the source too much.

Thanks,

Ben

1/18/2010 9:48:12 AM
Joe Audette
Gravatar
Total Posts 18439
View Posts

Re: SQL Server Compact Edition - Technical Implications

I think having a RESTful web service API would be useful for a lot of scenarios including this kind of sync orchestration across copies of sites.

Someone else has said they wanted to work on a REST API and would get back to me with a proposal but so far has not followed through.

Best,

Joe

You must sign in to post in the forums. This thread is closed to new posts.