-
Notifications
You must be signed in to change notification settings - Fork 235
TODOs & Enhancements
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
Refers to improvements in the Python distribution files, test scripts, Travis CI scripts and anything that revolves around "serving" neomodel
.
- Neo4J Python driver.
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 forcreate
) - Docs on exception raised by Structurednode.nodes.get is incorrect
- Implement Composite keys
- Implement
in
operator for fields of typeArray
- Implement
Path
data type resolution - Implement "...some kind of prefetch mechanism, like in Django..."
- Revamp
Relationship
semantics -
Enforce
Relationship
multiplicity (also, here). -
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 aTo
(orFrom
) relationship added towards nodes of the same type as the one attempted to be created, with its own relationship label and optional parameterprevent_loops
.
- This could lead to the definition of a
-
Introduce ordering by a relationship property attribute in
neomodel
queries- Also related to this
- Make
choices
parameter a callable - Enforce a Max Length Check *. Warn against using very long string attributes as indices
- Consistency of returned results from
neomodel
's query mechanism - Implement filtering on generic cypher expression
- 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: