Project Description
CIPl provides a common abstraction over various data stores. An application using CIPl can switch data stores by simply changing configuration options. Initially CIPl supports Sql Server, MySql, Amazon's S3, Rackspace Mosso, MongoDB, Cassandra, and various file system mappings. CIPl API also provides access to data over a service bus.

CIPl is an open source project provided and managed by Channel Intelligence.

You should consider using CIPl if
  1. You think your application may have to switch data providers at some point (e.g. Sql Server to MySql, Cassandra to Mongo, S3 toMosso)
  2. There is a possibility that your application may need to use different data stores in different contexts (e.g. Sql Server in some places, MySql in others)
  3. You don't want to get locked in to a specific data store
  4. You sometimes need to access the data store over a bus, sometimes locally, sometimes need to cache, sometimes don't
  5. You primarily need an object store, i.e. somewhere to efficiently store and retrieve complex objects using either an object identifier or simple queries

CIPl supports
  1. An API - A strongly typed interface to numerous underlying stores using a Data Provider layer
  2. Data providers - which include Sql Server, MySql, Rackspace Mosso, Amazon's S3, Cassandra, MongoDB, object per file, objects in a serialized dictionary and collections in an Xml file. See the Data Provider Comparison page for performance comparisons across the different data providers
  3. CLR type system integration -Support for complex CLR objects including properties and objects using types with subtypes, streams (not supported by some providers), object references, IList properties and IDictionary properties
  4. Item versioning - CIPl will keep version information for an item allowing you to reconstruct the item state at any point in its history
  5. Scalable properties which provide efficient support for multi-valued properties with dramatically varying populations (i.e. where most objects have very few values but some objects have very large numbers of values)
  6. Serializers - Fast, generated, Xml and Json serializers
  7. Rules engine - A simple rules engine that provides a common way to specify queries against the underlying stores
  8. Simple client protocol - Invariant behavior across the underlying stores - a successful operation will have exactly the same result (order not guaranteed) in terms of both data and information messages against all Data Providers
  9. Layering of the data providers - any data provider can be used as a cache for any other data provider
  10. Delegate based exception handling - exception handling strategies are up to the client
  11. Flexible and deferable configuration handling - the client controls when configuration settings are provided allowing sensitive and volatile information to be handled appropriately
  12. Adding a new data provider is a well-defined process requiring minimal change to existing code
  13. Pluggable components - Both the rules engine and the serializers are pluggable components and can be used independently of the other CIPl components

What CIPl Won't Do
  • None of the current CIPl Data Providers will map to an existing arbitrary database schema
  • CIPl does not support generalized aggregate or multi-structure queries (no joins, nested selects, exists etc)
  • There is no pessimistic concurrency style - CIPl objects can be time-stamped so you can do optimistic concurrency - though as yet the Data Providers are not required to enforce it

see the CIPl overview page for more details on the architecture and how CIPl works with the C# type structures.

see the Quick Start page for a run through of setting up CIPl and writing a simple CIPl enabled application

see the Developer setup page for instructions on how to setup, build and test CIPl

Why "CIPl"?

Last edited Sep 5, 2011 at 10:31 PM by PatrickThompson, version 34