Skip to content

Commit 4bfea8a

Browse files
committed
API v2: schema! Labels, indexes, constraints. [skip ci]
1 parent 0f13e7c commit 4bfea8a

File tree

1 file changed

+77
-0
lines changed

1 file changed

+77
-0
lines changed

API_v2.md

Lines changed: 77 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,7 @@ Sections:
1919
- [Cypher](#cypher)
2020
- [Transactions](#transactions)
2121
- [Errors](#errors)
22+
- [Schema](#schema)
2223

2324

2425
## General
@@ -311,3 +312,79 @@ class TransientError extends Error
311312
TODO: Should we name these classes with a `Neo4j` prefix?
312313
They'll only be exposed via this driver's `module.exports`, so it's not
313314
technically necessary, but that'd allow for e.g. destructuring.
315+
316+
317+
## Schema
318+
319+
**Let me manage the database schema: labels, indexes, and constraints.**
320+
321+
Much of this is already possible with Cypher, but a few things aren't
322+
(e.g. listing all labels).
323+
Even for the things that are, this driver can provide convenience methods
324+
for those boilerplate Cypher queries.
325+
326+
### Labels
327+
328+
```coffee
329+
db.getLabels _
330+
```
331+
332+
Methods to manipulate labels on nodes are purposely *not* provided,
333+
as those start to get into the territory of operations that should really be
334+
performed atomically within a Cypher query.
335+
(E.g. labels should generally be set on nodes right when they're created.)
336+
Conveniences for those kinds of things are perfect for an ORM/OGM to solve.
337+
338+
Labels are simple strings.
339+
340+
### Indexes
341+
342+
```coffee
343+
db.getIndexes _ # across all labels
344+
db.getIndexes {label}, _ # for a particular label
345+
db.hasIndex {label, property}, _
346+
db.createIndex {label, property}, _
347+
db.deleteIndex {label, property}, _
348+
```
349+
350+
Returned indexes are minimal `Index` objects:
351+
352+
```coffee
353+
class Index {label, property}
354+
```
355+
356+
TODO: Neo4j's REST API actually takes and returns *arrays* of properties,
357+
but AFAIK, all indexes today only deal with a single property.
358+
Should multiple properties be supported?
359+
360+
### Constraints
361+
362+
The only constraint type implemented by Neo4j today is the uniqueness
363+
constraint, so this API defaults to that.
364+
The design aims to be generic in order to support future constraint types,
365+
but it's still possible that the API may have to break when that happens.
366+
367+
```coffee
368+
db.getConstraints _ # across all labels
369+
db.getConstraints {label}, _ # for a particular label
370+
db.hasConstraint {label, property}, _
371+
db.createConstraint {label, property}, _
372+
db.deleteConstraint {label, property}, _
373+
```
374+
375+
Returned constraints are minimal `Constraint` objects:
376+
377+
```coffee
378+
class Constraint {label, type, property}
379+
```
380+
381+
TODO: Neo4j's REST API actually takes and returns *arrays* of properties,
382+
but uniqueness constraints today only deal with a single property.
383+
Should multiple properties be supported?
384+
385+
### Misc
386+
387+
```coffee
388+
db.getPropertyKeys _
389+
db.getRelationshipTypes _
390+
```

0 commit comments

Comments
 (0)