Extract the driver out of the library

[mariusconjeaud]

Extract the driver out of the library

[mariusconjeaud]

Maybe an interesting read is how they did it in the official Neo4j Java OGM : https://neo4j.com/docs/ogm-manual/current/reference/#reference:connecting

Basically, they have a SessionFactory object that contains every method that interacts with the database ; and you can create it with both options that you describe in point 1) : configuration (credentials,...) or pass a driver.

The good size of this SessionFactory object is that it makes you aware of what is happening driver-wise (session, transactions, ...) ; but the downside is that... you need some understanding of drivers so it makes the library a bit more advanced.

The limit of using this as inspiration is that the scope of neomodel's Database object is smaller than the scope of SessionFactory : it has transaction and ad-hoc Cypher queries capabilities, but all the OGM classes management (save, retrieval, etc...) is not part of Database class. So when you retrieve some nodes like MyNode.nodes.all() then you still need to point to which driver you want to use, it's not contained in the MyNode class (as opposed to this Java library where you point the "session" object.

[mariusconjeaud]

OK I've done some reading about Neo4j-OGM and SDN and here's my conclusion on what we can do as a first step :

• Main idea is that we go for a simple first step, which is allow users to pass Database a driver instead of configuration when initializing their app. Then they can benefit from any advanced driver option that neomodel doesn't cover ; while the default config as today is still available for default use cases
• Add a method to explicitly close the driver, and insist that users call it at the end of their app's lifecycle ; and make sure we also call it before set_connection.

This has two advantages :

• Shouldn't be a breaking change
• First step towards more advanced driver usage that can spark discussion about "What next"

[martinralfreindl]

Hi all - not sure if the following is going to add, but wanted to chime in quickly.

I'm a user that literally started using neomodel today, and I come from the SQLalchemy ORM world, where I workheavily with SQLAlchemy sessions. From my basic understanding SQLAlchemy seems to use a setup more similar to Neo4j Java OGM. Basically in SQLAlchemy we use a sessionmaker to manage sessions, and we pass our engine / driver into that (LINK).

I'm obviously biased by my experience, but this approach feels much more transparent and intuitive to me. When setting up, I could see how my engine connects to the session, and then management via the session object is super simple.

Might be worth looking into SQLAlchemy approach as well for that reason.

P.S.: Thanks for the amazing library. Makes my life better <3

[mariusconjeaud]

An open question I have is if we should allow the users to set the driver, just like they would call db.set_connection()

For simple use cases where applications do use the same driver across their whole lifecycle, this prevents users from having to pass the driver for every single action like MyNodeLabel.create() or MyNodeLabel.nodes.all()

Then we can make the driver argument optional in all actions requiring a driver - if None is passed we use the one stored inside the db singleton, otherwise we use the one passed as argument.

Then maybe we get the best of both worlds ?

[aanastasiou]

My vote would be to allow users to set the driver in the manner you describe (Marius). However, it also depends on how the driver object behaves:

1. Does it maintain any connections open for the duration of its lifecycle? If it does, then it might be best that we manage the whole cycle ourselves internally and in this case the API changes might be minimal. You still supply username, password or a whole BOLT URL, these are stored locally and used on each action that requires instantiating a driver object. Otherwise (even easier) we use the user supplied object directly.

2. How does the driver behave with concurrency? This might be a more general consideration but we need to keep this in mind especially for web apps.

[mariusconjeaud]

That sounds like what Neo4j Java OGM also does indeed !

I agree that this is intuitive. However, we also have to find a middle ground, to provide valuable new features, and not breaking too many things - or at least, it should be extra clear that there are big breaking changes coming up.
I initially thought to bring in breaking changes in the next major release - 5.2.0 - but then it didn't feel right anymore.
Maybe this is something we could think about and potentially prepare for a BIG major release, like 6.x. Given that Neo4j started deprecating some features in the driver in version 5, they will probably be removed in version 6, so that might have some breaking impact anyway.

Let's keep that in mind !

[mariusconjeaud]

Starting from release 5.2.0, you can either pass a DATABASE_URL to use neomodel-managed driver ; or pass your own driver instance to the config and set_connection method. This allows you to manage your own driver, and leverage all of its existing features that you might be interested in and that would not be covered by neomodel.