Code Artistry - No SQL Databases

• Very large collections of data
• High throughput with data from streams
• support tree or graph models for its data
• support heterogenious collections of data

• Project #1
  Develop the concept for a basic noSQL application. We capture the concept with an "Operational Concept Document" (OCD).
• Project #2
  Implement most of the concept and perform thorough functional tests.
• Project #3
  Develop the concept for a remote noSQL application, based on Project #2, using a message-passing communication service.
• Project #4
  Implement the remote noSQL database server and do performance testing.
• Project #5
  Create and document a data management service architecture using the ideas developed in the first four projects. This service will provide the communication and state management infrastructure for a large Software Development Collaboration System composed of a federation of cooperating servers and client controllers.

• Create items described by metadata and holding an instance of some generic type.
• Create and Manage a Key/Value database with capability to store and delete Key/Value¹ pairs.
• Edit Values
• Persist database contents to an XML file².
• Augment database contents from an XML file with the same format as persisted, above.
• Support a variety of queries, both simple and compound.
• Support demonstration of all functional requirements through a series of discrete tests with display to the console.

  public class Value<Key,Data>
  {
    // public methods providing
    // access to private data
    private string name;                           // Note: you may choose to capture
    private DateTime timeStamp;                    // these Value states as properties
    private string description;                    // rather than private data items.
    private List<Key> children;
    private Data payload;
  }
    

  public class noSQLdb<Key,Value>
  {
    // public methods providing database API
    private Dictionary<Key,Value>                   // The dictionary should not be a public property.
  }
    

1. Issue: - Demonstrating Requirements
   Students only get credit for requirements they clearly demonstrate. No inputs other than a supplied XML file to load the intial database are required³. The only output required is a console display.
   Solution:
   This requires careful orchestration of a series of tests invoked by the test executive and supported by processing in the Display package.
   Impact on Design:
   It will be effective to provide a method for each test that announces the Requirement number and displays db state before and after each change.
2. Issue: - Designing Queries
   Statement and solution(s) are left to the students.
3. Issue: - Sharding
   Statement and solution(s) are left to the students.
4. More Issues: - Left to Students.

• A QueryPredicate is a function that accepts a db key and returns true or false depending upon the processing of the predicate function. For this noSQL db, the processing will look for specific conditions in the element bound to the supplied key, e.g., name, description, time-date stamp, children, or payload. We will use C# lambdas to implement QueryPredicates. See LambdaDemo for code that is close to what we need here.
• A simple query then, consists of applying the QueryPredicate to each of the keys in the database and collecting all of the keys for which the predicate is true. That's what DBFactory<Key, Value> does.
• A compound query is a chain of queries, each query using the keyset returned by the previous query⁵. We'll need some way to manage those returned keysets - QueryEngine manages that process, using DBFactory<Key, Value>s to wrap return keysets. At each step QueryEngine constructs a DBFactory<Key, Value> instance, applies its next QueryPredicate to that instance, to get the next keyset.