TODOs & Enhancements

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.

• Neo4J Python driver.
  • Don't pin the version of the neo4j driver
    • ACTION: Pin the driver but update code so that it works with the latest version.

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:

• Properties beginning with underscore can be ignored by neomodel
• Email property seems to be required
• Bad type in string docs of get_or_create (Same thing also true for create)
• Docs on exception raised by Structurednode.nodes.get is incorrect

Features

General

1. Improve neomodel's in operator to work over any iterable
2. Implement Composite keys
3. Implement a "migration tool" that can infer and apply modifications to a neo4j dbms so that it reflects the models
4. Implement in operator for fields of type Array
5. Implement Path data type resolution
6. Implement "...some kind of prefetch mechanism, like in Django..."

Relationship management

1. Revamp Relationship semantics
   • Have the label of the relationship declared along with the relationship class to prevent assigning a model to the wrong relationship label. This would also help with inheritance as it would be impossible to assign the wrong relationship label to a derived class.
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

Date* Properties

1. Update the data marshaling to convert from and to native data types

Query management

1. Consistency of returned results from neomodel's query mechanism
   • Implement consistent use of NodeSet to enrich querying capabilities
     • Possibly also related to returning Django QuerySet from neomodel
     • Possibly also related to match() returning Traversal rather than NodeSet
2. Implement filtering on generic cypher expression
3. Review and expand the use of backtics

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. Consider lazy 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.