A common concern with SSDS, and a common question I get in many presentations I've given is how to handle concurrency and entity versioning. Suppose you have the following sequence of events: By default, SSDS will just accept the last Update and overwrite any changes made in between. If you want SSDS...

Well, too bad...No, seriously now, as I mentioned in a previous post , we developed a "mock" (but fully functional for LitwareHR's purposes) offline SSDS proxy to enable development independently from the live SSDS service. The offline proxy is included in LitwareHR latest release, but by default...

The latest version of LitwareHR is now available for download here . From our CodePlex site: This new enhanced version of LitwareHR includes the following new features: Upgraded codebase for SQL Server Data Services support New "DataModel" New infrastructure for data access to SSDS (including...

Tim Jarvis raised a good point in my post on cross-container queries which is: how to handle paging? SSDS currently supports a very simple paging pattern that uses the entityId . By design, the first 500 entities will be returned, but the entities will be returned in entityId order. So, you can get the...

Here's an end-to-end demo of LitwareHR using SSDS. The total demo lasts about 11 min and you will see: Tenant Provisioning and customization (takes the first 5 min approximately). I show the initial tenant provisioning (creation of a new tenant in LitwareHR, initial configuration, etc) and then...

Our current implementation of cross-Container queries follows a very common pattern and roughly looks like this (no exception handling shown for simplicity): public List<T> CrossContainerSearch( string [] containerIds, string query, SearchDelegate searchDelegate ) { Event[] events =...

In SQL Server Data Services, the scope of a query is bound to a Container , but in LitwareHR we had a requirement of searching entities across multiple tenants, and because in our implementation each tenant gets its own Container, we had to create a way of performing queries (the same query to be more...

SQL Server Data Service is well...an online service. That means that you have to be connected to the network 100% of the time if you are using it. What if you are not connected? well...you know the whole story. Our goal while developing LitwareHR was to actually make the dev team as independent and autonomous...

In most applications, the distance (in terms of bandwidth and latency) between the store (the database) and the application logic (like the web servers and web services) is usually very small. The connectivity between these two components is usually very reliable and with very high throughput. But because...

The heart of LitwareHR implementation on SSDS is in it's data access layer of course. In fact, we created two different, but functionally equivalent implementations: one runs against SQL (LitwareHR's original implementation) and a second stack that runs against SSDS. Of course they are mutually exclusive...

SSDS's application model and features map quite nicely to our customization and multi-tenancy requirements in LitwareHR. A significant amount of code in LitwareHR is in the generic, multi-tenant, extensible data access. Our multi-tenant database performance guide, compares different extensibility approaches...

Today, in his keynote, Ray Ozzie announced a new "cloud service" available from Microsoft: SQL Server Data Services (code name: Stika). It's a good that he announced it, because now I'm out of quarantine and I can talk about it :-). For the last 2 months I've been working very closely with the SSDS...