This project has moved and is read-only. For the latest updates, please go here.

Best Practices .net

Sep 22, 2015 at 3:07 PM
What is the best practice with the ctx ?
Should I use a singlton per session? Creat the ctx for the session and return the same on always. Never dispose.
A unique ctx per call? (wrapped in using for dispose.

-- so far BrightStarDB is very nice -- it definitely has a bright future ... hope it keeps going a long time.
Sep 22, 2015 at 3:26 PM
Also -- I'm using a simple embedded connect string -- @"type=embedded;storesdirectory=.\\;storename=TestDB;optimisticLocking=true"; that maps to bin/debug/testdb -- when I put that into polaris it finds the folder but shows no content ? Yet the test application works fine...

Any reason for this?

Sep 22, 2015 at 7:33 PM
I'd also like to know how you set unique keys?... is the [Identifier("UserProfile", KeyProperties = new[] { "Id" })] type of attribute set only once. Is that the only key whether it's single or composite? Is there no value in assigning keys for other fields?
Sep 22, 2015 at 9:50 PM

The best approach with the context is a unique context per call wrapped in a using for automatic disposal.

With your Polaris set up it sounds like Polaris might be configured to look in bin/debug/testdb, try pointing it at bin/debug. However, be aware that if you run two applications (e.g. Polaris and your own application) both using an embedded connection to the same store directory you will potentially hit file sharing issues as one application locks the file for read and creates updates that the other application doesn't know about. In these sorts of scenarios I recommend instead running a BrightstarDB server and using the REST connection; or simply make sure that you don't run both applications together!

Pseudo-unique (GUID) keys will be generated by default, you don't need to do anything more than declare an Id attribute of type string: e.g.
public interface IPerson {
  string Id { get; }
You can also use ID or {EntityName}Id (e.g. PersonId) or {EntityName}ID for this field. If all you need is a single unique identifier and you don't care that its a long-ish hex string, then you are all set. You should really only need to use the KeyProperties attribute if you want to construct a composite key from other property values (e.g. using the ManufacturerId and ProductId to uniquely identify a stock item).

Hope this helps! Thanks for using BrightstarDB and please let us know if there is any further help you need!