I need to deliver a DB with my app, then periodically update it from a remote server, can I do this?

Dec 3, 2010 at 10:32 PM

Hi all.

 

I'm writing an app for WP7 that will be delivered with a decent sized database, and fill in from the cloud as needed. I need to be able to do a few things, and it's not immediately clear from the docuemntation if this fits the bill.

 

  1. Build a database on the desktop, and serialize in the format required by the phone database. if I have to write an exporter for this, no big deal. This seems easy given the documentation.
  2. Pre-install that database when my application is installed. Ideally this would put the database in isolated storage. I think you can copy an embedded object to isolated storage easily enough, but that would double the application size. The data is probably fairly compressible, so I could zip this in the app and install it on first run. Seems doable.
  3. When the application is running, I would like to use the database for my normal runnings. This seems no like no problem if 1 and 2 can work.
  4. Update the database from the cloud when a new version is available. I'd rather do this than update the app in the marketplace, and ideally it would involve downloading a new zip and decompressing into isolatedstorage. If 1 2 and 3 work, I can see this working.

Does anyone have experience with any part of this. I guess I can write an exporter for my SQL Database, creating the subset I want to have on the phones, and write that out by making a Silverlight app, then taking whatever file it generates and embedding that in my project. I can figure out the zip etc later, and I can figure out the updates later. 

Can anyone validate that I'm thinking about this correctly?

 

Also, how much overhead is there in this database? I'd imagine it makes sense to generate the indexes once on the device, to keep deployment small. Anyone have timings? Like creating an index on 20,000 int keys? I can't imagine it'd take all that long.

Thanks in advance for any insight or shared stories about how you've done something like this.

Coordinator
Dec 6, 2010 at 1:11 PM

So it could do all of that, but I will provide the caution: Sterling is intended to easy object-based serialization of objects. If you are trying to port a database that is a heavy relational database, it may fall short. In that case you might want to look at some existing alternatives, for example the commercial solution Perst by McObjects. That is a full transaction database with relations, etc.

Sterling makes sene with two very specific strategies:

1. You want to cache a lot of objects without the headache of creating all of the plumbing necessary to manage them, and

2. When you are querying, you typically do a lookup of one or two key fields for lists/etc and want this to be fast, but can take a little more time de-serializing the full record when needed

For your items above:

1. Sterling can easily be used on traditional .NET with non-Silverlight isolated storage. I focus on the niche for Silverlight but it's possible to reference the Sterling source as a .NET project, then build your code to basically serialize via Sterling and then zip up the iso bytes (we are looking into a feature like this as well, it is often requested)

2. Yes, its doable

3. Yes

4. This can be done as well but would require a little more work ... I am working with a few other users to strategize the best ways to manage versioning and will be publishing some examples soon

 

Dec 7, 2010 at 10:21 PM

Thanks. I was going to flatten the subset of data somewhat in my export, so I imagine it'll be ok speed wise. The only potential problem I see is that I have image thumbnails stored in the database here I'd like to get onto the device, so I'm not certian what to do with those yet, but I'll work something out. I can manage a versioning strategy, even if it's something as clunky as having a single record in a table that has the version and comparing that up against a webservice which supplies current version and url. Should be enough for what I'm doing.

I appreciate the reply.