Suggested Features

Coordinator
Oct 24, 2010 at 12:28 AM

Guys and ladies,

Please let me know if there are any new features you would like to see in the upcoming releases.  I am always open for suggestions.

Thank you.

 

Sergey

Oct 24, 2010 at 6:29 PM

Hm, the only problem I have right now, is the memory profile.

I think your solution deserializes all stored data into the main memory. That is good for small amounts of data.

I fear that my app will produce more and more data over time and then it will be

1) very slow during initial startup (all data will be deserialized into the ObservableCollection objects).

2) possible crash because of too much memory used.

3) Saving data would take a longer and longer time.

What I wish would be a Linq enabled database where only the selected items are actually loaded from the isolated storage.

Some support for decoupled loading in ListViews will be appreciated then too (as the performance might get lower then)...

Currently I am thinking about switching to another db. This NinjaDB seems to be able to use Linq as well. But so far I have not done more than checking out the demo. They have implemented a huge amount of support code to get the save process more efficient (no need to completely serialize everything). But porting my app over would take some time. But I have to do it fast as its already in Marketplace (probably noone is using it) - and data migration is an issue.

Hope that gives you some inspiration :)

Markus

Oct 26, 2010 at 5:48 PM

I would like CompiledQuery for querying speed up.

Coordinator
Oct 28, 2010 at 2:06 AM

A couple of notes

You are correct that the data is deserialized into memory, but only on demand.  If you use lazy loading option, the data is loaded into memory when you issue a query.  Saving data taking longer is definitely a concern.  My other concern is that the phone is ultimately a small device, so large amounts of data will likely cause performance issue no matter what DB you use.  I think if you are dealing with a ton of data, you should consider storing it on the cloud and only pull the data you need to run...  I am going to give saving optimization some though.

Thanks for the feedback, Marcus.

Coordinator
Oct 28, 2010 at 2:09 AM

Thanks, GMz.

Unfortunately, there is no true DB engine on the phone, and this DB is no exception.  Compiled queries are typically applied to true DB engines.  Do you have something specific in mind that I am totally missing?

Thanks

Nov 27, 2010 at 8:39 AM

One request would be to store the data in JSON format (or even better - in binary) to

1.) speed up the deserialisation/serialisation process from/to isolatedStorage (most important one I think).

2.) Save space on phone memory

3.) Save time backuping/restoring the data via WebService (I wrote a tool for hosting a webservice for saving/restoring the complete database to my PC).

I have not tried the async save feature yet - but are you securing that during the save-process nothing is added to the storage system? Otherwise that could lead to ugly states inside the database or application...

Coordinator
Nov 27, 2010 at 12:20 PM

No, I am not protecting save for the following reasons. The best I could do is throw an exception, which will likely kill your app. I have decided that it would be better to utilize a standard approach to save data in any Silverlight application – you simply block user interface with a screen showing some animation letting them know the data is being saved. Also, I do not know enough about your objects to keep them from being changed.

Thank you for your suggestions. I have not had a chance to work on other serializers primarily because I am doubtful that I can make them work better than Microsoft guys. I will however investigate this possibility in the near future, hopefully within the next few weeks.

Thanks

Sergey