I'm trying to use a embedded RavenDB database for a small desktop application written in C# and WPF (using MVVM). Right now I'm asking myself how to handle the sessions the right way. I'm loading some items at the start of the application which may get updated at some time.
What's the best way to handle that?
The solutions I've tought of or read so far are:
use a single session for the whole lifespan of the application - I haven't read about that one, so I don't think it should be a preferred solution
open a session after an object has been changed, load the object again from the server, use a library like ValueInjector to overwrite all values from the local object and save those changes - seems more like a hack fix
Save the etag for each object and use it with the store method to replace the complete object on the database - doesn't seem like a good solution either
So neither of these possibilities seem very good and unfortunately 90% of all samples seem to be for MVC controllers only.
Is there any way to reattach an object from an old, closed session? Or is there any other recommended way to achieve what I want?
This article talks about NHibernate, but pretty much all of it applies to RavenDB session management as well.
http://msdn.microsoft.com/en-us/magazine/ee819139.aspx
Related
I have an application that uses an MS-SQL-Server to store it's data. We will roll out the application in several steps, so users can test first basic functionalities and we add functions over time.
Probably, this will cause changes to the database. In early stages, we can just drop the whole database and create everything anew with a script. But eventually, users want to keep their test data. For example, if I add a new column to a table, I don't want to delete and create anew the whole table, loosing all the data the user has stored so far in the process.
So, what I need is a script, that updates myDatabase v1.0 to myDatabase v2.0.
My question is: What is the best way to create such an update script? Do I have to manually keep track of all the changes and then assemble the update script myself? Or is there a function which could (semi)automatically create the update script from the old and the new database?
And finally, what is the best way to apply this patch? I have a ASP.NET Web-API so, I could create a controller api/updates/v1.0-to-v2.0
How would the code for applying the script at the server would look like?
Thanks in advance,
Frank
I'm working on a solution to this very problem, check out dbpatcher.com the software that I've created will help to make migrating database changes easier. I'm putting together the website at the moment so would welcome feedback. The program itself isn't yet available, as I'm trying to figure out the details for publishing.
If this is an on-going concern (corporate), you should really consider different environments, ie. test, staging and production. This way you can test your deployments and database scripting changes in a pristine environment (something that looks exactly like production).
Given that, to answer your question, there really isn't a good way to do this. I've seen people use diff tools to detect the differences between schema's, and it creates scripts to sync two schema's, but it's not fool proof.
I find that scripting the changes and combining that with version control and an installation procedure (manual or automated) is the only way to get consistent results, and even that fails sometimes.
Code first entity framework is attempting to solve that issue, but it's not an option for a number of shops.
I would love to see a good tool to manage this, but the set of diverse frameworks and human error are the biggest problems here.
In terms of down time, there really is no such thing as live in-place upgrades of web applications. There are ways to mitigate it to a minimum, like update one set of a load balanced Web/App server at a time and then fail users to the new software. If your doing table alterations, the likelyhood that your not going to lock the table and interrupt your users are pretty low.
Thanks for your replies!
I have different environments, my concern is how to change the database schema without loosing data in the production environment (if possible, of course). Downtime is not so much a problem. As I am not productive yet, I simply create a script to recreate the whole database, but when the user has live data stored, he would probably be a bit ... upset.
There is a nice tool from redgate, that seems to solve that problem, but I did not checked it yet.
I want to be able to maintain a count and a last accessed date across application loads for a web service polling application. I'm not too sure what the best way to do this is. I dont like the idea of storing that data in a database as I would have to create one specifically for the purpose. What other options do I have and are there any particularly nice ways of keeping application state between subsequent runs of the app?
Persisting data eh? I suggest a database or file.
File solutions you can just XML serialize to a file and load it again when the app starts.
If the data is shared or might ever grow, then a database is probably the best solution. You can find one that fits your need among the many free projects if you wish:
couchdb
mysql
postgres
mangodb
membase
sqlite
etc
You could roll your own solution that doesn't involve a database, but most likely there is one that fits your needs and learning it would be useful beyond just the project at hand.
Don't be afraid to make a 'configuration' style table for your website, that simply has only a few rows and let's you store runtime information as needed.
Perfectly fine.
I'm trying to prepare to build a database driven .net application and I have hit a roadblock early on due to my lack of knowledge on this topic. Searching around didn't yield anything so here I am asking for help.
I'm receiving weekly data in xml format that will be added to a database and then reports generated using that data. I have a limited license on the xml files so only I can download them and I need to get the results to my end users as well. As far as I can see, I have 2 options:
Feed the data from the xml files into a web hosted database and then have each user connect to the database.
Upload the xml data to a server, have each user download it and keep a local copy of their own database. I'm thinking this will invalidate my license to the original data.
Things / questions of note:
The database holds weekly sports historical data for about the last 10 years.
I need to limit access to the database to only subscribed users.
I'll need to decide how the database will be built.
I need to decide what kind of hosting I'll need.
As you can see, quite an ambitious project for someone new to this. I haven't asked any specific questions so far:
What kind of hosting solutions shall I look for?
Should I use SQL? (Complete newbie on this subject)
Should I use clickonce and then host the application?
Do you have any book or tutorial recommendations that would cover a project like this?
Do I need a script to feed the xml into the database if I go that route? Will that script reside on the server and do it automatically even if I'm not there to instigate it?
I hope the general topic isn't too vague. I tried to actually ask specific questions on it and I'm aware I don't have any code to show as it's just in the early stages of thinking.
The question is a bit vague since you are early on in the decision-making process. However, I do believe that I can offer some help in directing your thinking as you proceed. I think in the situation you are describing, one key thing you should consider is to host your data via JSON/WCF/REST. If you look into these technologies, you will see that there are different ways you can offer your data based upon your developing requirements. For example, how are you going to do authentication? Are you going to allow third-party clients?
What you really don't want to do is allow direct database access, even for authenticated users. Instead, put something in front of it. If you are working in the .NET space, look into all of the different things WCF offers and pick one based upon what fits best. Once you pick that, then you will know what you need for hosting and deployment. Even if you are going to provide the clients as well as the server, this is still a good way to protect your data and provide a way to expand your offering in the future.
I have a WPF application that stores a large amount of information in XML files and as the user uses the application they add more information to the XML files. It's basically using the XML files as a database. Since over the life of the program the XML files have gotten quite large, and I've been think about putting the data on a website, I've been looking into how to move all the information into an SQL database.
I've used SQL databases with web applications (PHP, Ruby, and ASP.NET) but never with a Desktop application. Ideally I'd like to be able to keep all the information in one database file and distribute it along with the application without requiring the user to connect to a remote database (so they don't need an internet connection - though eventually it would be nice if could compare the local file's version with one online somewhere and update if necessary) and without making them install a local database server on their computer. Is this possible?
I'd also like to use LINQ with any new database solution so switching to a database doesn't force to many changes (I read the XML with LINQ).
I'm sure this question has been asked and that there are already some good tutorials on the subject but I just can't find them.
SQLite is a good embedded database that you can ship along with your application. I have not done much more than some prototyping with it, so I personally cannot say with 100% certainty that it will meet your needs. But from what I have read, and what little I have written against it, it seems appropriate for the job.
SQLite Homepage
ADO.NET Provider
If you know how your objects are all going to fit together, you could serialize them/deserialize them to store them on disk as a set of ProtoBuf objects (depending on their size, of course). I've found that it's a pretty simple, elegant solution to storing a set of interconnected classes. Each class that should be savable, all your data, can be serialized using this method, and then restored as necessary.
Here's the .NET link to it.
This is a previous question I asked on SO, and got several good responses.
I'm new to NHibernate (my 1st big project with it).
I had been using a simple method of data access by creating the ISession object within a using block to do my grab my Object or list of Objects, and in that way the session was destroyed after exiting the code block.
This doesn't work in a situation where lazy-loading is required, however.
For example, if I have a Customer object that has a property which is a collection of Orders, then when the lazy-load is attempted, I get a Hibernate exception.
Anyone using a different method?
Session management:
http://code.google.com/p/dot-net-reference-app/source/browse/trunk/src/Infrastructure/Impl/HybridSessionBuilder.cs
Session per request:
http://code.google.com/p/dot-net-reference-app/source/browse/trunk/src/Infrastructure/Impl/NHibernateSessionModule.cs
check out the SummerOfNHibernate webcasts for a great tutorial... What you're looking for specifically doesn't come until webisode 5 or 6.
Keep your session open for your entire unit of work. If your session is life is too small, you cannot benefit from the session level cache (which is significant). Any time you can prevent a roundtrip to the database is going to save a lot of time. You also cannot take advantage of lazy loading, which is crucial to understand.
If your session lifetime is too big, you can run into other issues.
If this is a web app, you'll probably do fine with the session-per-httpRequest pattern. Basically this is an HttpModule that opens the session at the beginning of the request and flushes/closes at the end. Be sure to store the session in HttpContext.Items NOT A STATIC VARIABLE. <--- leads to all kinds of problems that you don't want to deal with.
You might also look at RhinoCommons for a unit of work implementation.
Since you are developing a Web App (presumably with ASP.NET), check out NHibernate Best Practices with ASP.NET at CodeProject.