Skip to content

TODOs & Enhancements

Athanasios Anastasiou edited this page Mar 7, 2019 · 11 revisions

Introduction

This section of the Wiki is a review and summarisation of 'neomodel's list of issues, as of March 2019.

At its 3.3.1 release, neomodel already contains a number of very useful OGM characteristics for Neo4J's backend. These have been added by approximately 28 contributors (via a Changelog enumeration) who have either added features out of their own use-cases or by responding to issues raised by neomodel users.

Some of these "issues" however represent ideas that would take longer to incorporate to neomodel, primarily because they imply some form of redesign.

In view of an upcoming major release, this document aims to collect together a number of features contributors might want to consider working on.

Please note: The list has not been finalised yet. Work in progress

Improvements

Infrastructure / Framework

Refers to improvements in the Python distribution files, test scripts, Travis CI scripts and anything that revolves around "serving" neomodel.

Documentation

The documentation would benefit from a thorough proof reading in general to ensure that examples are consistent and match the functionaltiy of the current release.

More specific issues are as follows:

Features

General

  1. Implement Composite keys
  2. Implement in operator for fields of type Array
  3. Implement Path data type resolution
  4. Implement "...some kind of prefetch mechanism, like in Django..."

Relationship management

  1. Revamp Relationship semantics
  2. Enforce Relationship multiplicity (also, here).
  3. Introduce prevent_loops constraint for reflexive relationships
    • This could lead to the definition of a ReflexiveRelationship. Explicitly setting the relationship type to "Reflexive" would imply that the node gets a To (or From) relationship added towards nodes of the same type as the one attempted to be created, with its own relationship label and optional parameter prevent_loops.
  4. Introduce ordering by a relationship property attribute in neomodel queries
    • Also related to this

Properties

StringProperty

  1. Make choices parameter a callable
  2. Enforce a Max Length Check *. Warn against using very long string attributes as indices

DiskFileProperty

  1. Implement a Property for handling files (stored externally) as properties

DecimalProperty

  1. Implement a Property for handling monetary values

Query management

  1. Consistency of returned results from neomodel's query mechanism
  2. Implement filtering on generic cypher expression

Implement / Revamp batch operations (potentially asynchronous)

  • Any interaction with the database layer via neomodel is known to be slow. This is because every interaction is translated into a query and every query runs into its own session. The alternative to this currently is to start a transaction which will effectively gather a number of queries (within the transaction) and apply them in one big block to the database directly.
  • Another way that this is dealt with is by writing CYPHER queries that accept a large number of "parameters" in the form of an array that is "unwinded" before applying the operation to the database. This is currently used within neomodel in what has been called Batch Operations.
  • This however is limited to the CREATE and UPDATE operations and a number of different issues have been created so far that point towards more general aspects of "batch operations" that could be added to neomodel. These are as follows:
    1. Make clear_neo4j_database iterative
    2. Generators for large datasets
    3. Considerlazy instantiation of queries for DELETE, UPDATE operations

Transaction management

  1. Guard against cluster structure changes (also, here)
  2. Improve client-server sync for specific operations
  3. Implement nested transactions
  4. Close sessions explicitly
  5. Implement Neo4j bookmarks for causal clustering synchronisation.
Clone this wiki locally