Hi all,
since I don't agree with some of the comments from Robert I just want to
give my feedback as well.
> > Well first I found I couldn't run it without the Shell and JTA jars.
I
> > wouldn't mind but the documentation implied that if you just want to
> > embed a graph db and go you only need the main jar.
I think it is good to keep things separated. There is one jar for Neo
itself, and another jar for the JTA stuff. The JTA API has a different
lifecycle than Neo and is not under control of the Neo team, so it
should be kept separated. The shell you don't need for runtime, so there
are only 2 jars, which is absolutely acceptable.
> > The EmbeddedNeo name also caused me a lot of confusion. I read that
as
> > being "in-memory" in the style of Hsql or Derby. I didn't understand
> > that the path I was passing had to be a real directory rather than a
> > virtual or conceptual path. I then felt that if the process was
going
> > to create a lot of files and be quite fussy as to whether it was
> > explicitly asked to shutdown then it would actually be easier to
have
> > it run as a server process.
??
My perception at the first contact with Neo was that it is a database,
which is supposed to make things _persistent_. So for me it seemed quite
logical to specify some directory where to put the database files.
Embedded typically means that the lifetime of the database engine is
bound to the lifetime of my Java process, and this is what you get with
the EmbeddedNeo.
> > Once everything was running I had two issues. The first was having
to
> > open a transaction just to read data seemed wrong. I see pure read
> > data as being one of the most common tasks and if I am not going to
be
> > changing anything I don't see why I have to manage a transaction.
Agree. There should be a shared (read-only) view on the data which does
not require to have a transaction, and isolated transactional views for
manipulating data.
> > Secondly the property setting felt quite cumbersome, I would expect
to
> > be able to set multiple Properties via a Map<String, type> for
> > example. I also think it should be part of the Core API to retrieve
> > Nodes by Property although if I am reading the documentation
correctly
> > I think that might already be on your roadmap.
I have never missed this one. I think typically the Neo API will not be
used "raw", but will be wrapped by a domain model, where the individual
member accessors will translate into node properties and relationships,
like:
MyDomainClass {
Node node;
setName(String name) {node.setProperty("name", name);}}
> > Again it might be just to do with the name but I would not expect to
> > have to explicitly shutdown an Embedded process. The shutdown should
> > be on the finalizer for the server. Once an Embedded object goes out
> > of scope it is, to my mind, not in use any longer.
Java finalization is evil, as it does not have a predictable behaviour
and in extreme cases could even lead to out-of-memory situations (if the
Finalizer thread works slower than other threads that create new
objects). I would not rely on some finalize method to shutdown the Neo
engine. Registering a shutdown listener at the VM is a better way. This
could be done by Neo by default (close the service if it is still
active), but there should still be a public shutdown method for
explicitely stopping Neo by the application. There are scenarios where
Neo must be closed while the VM still remains alive.
Regards,
Peter
_______________________________________________
Neo mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
