Motivation

Algorithms operate over data structures, not database resultsets.

neoads attempts to treat the database as an extension to the computer’s memory in the seamless way possible. This is achieved by abstracting the data marshalling required to convert data to and from the backend’s data format to native Python objects.

This approach offers the following benefits:

  1. This “exended memory space” becomes accessible via the Python data model, in which:

    • A neoads.AbstractSet behaves like a Set

    • A neoads.AbstractMap behaves like a dict; and

    • A neoads.AbstractDLList behaves like a List.

    • For more information please see section Abstract Data Structures

  2. neoads can work with any existing data model with only minor changes to the data model. This means that if your data model has (for instance) an entity Customers, you would be able to create a list of Customers sharing a particular property via neoads.AbstractDLList.

    • This is taken one step further in neoads as certain operations are directly translated to queries, instead of moving large amounts of data back and forth between a client and a DBMS. This opens up possibilities for distributing data processing load between a client and a server rather than viewing the server as another serialisation target. See also point #3 below.

    • For more information please see section Class Diagrams & Data Modeling

  3. neoads data structures can stand in as targets of READ Cypher queries. This means that you can quickly create sub-sets of data and recall them instantly (“frozen resultsets”), rather than having to run queries every time you require them [2].

  4. The backend representation that supports all this functionality uses a “self-describing” schema [1], which means that the data structures can be accessed / queried without neoads. That is, the data are still readable in the backend, even if they have to be accessed by raw queries.