Great initiative.
Instead of storing such information in a plain-text file it could be
stored in the neo4j store itself (as a sub-reference node or
something).
I don't know if that'd be good/better though.
2010/1/4 Tobias Ivarsson tobias.ivars...@neotechnology.com:
Hi,
Neo4j today is made up
Hi everyone,
I have an issue which I would like your opinion on... It's mostly a question
of code aesthetics, to be honest, but still...
When I look in my code I see myNode.getProperty(SOME_PROP, null);
everyehere... The reason for this is that I if I called
myNode.getProperty(SOME_PROP) I'd
That's an interesting idea. However something in my gut tells me that it's
not good/better:
* It's still open for people to mock about with, however now it's in the
node space using up a relationship type that is now unusable by the
application (at least as a relationship from the reference node).
Well, I think it's generally a good thing to be able to distinguish
mandatory stuff from optional stuff... and that's the use case of
those two methods.
If you're getting a property which must be there in your domain you
shouldn't have to check for null in all those cases, it feels so
C-like to
(First of all, I am sorry if you all got more then one copy of my previous
mail... problem with my mail-account...)
Thanks for your thought! I agree, but I'm still uncertain of what I think is
best... I just get this feeling, you know? It might be that I deep down use
the metaphor of a value
Hi!
Mattias Ask:
that isn't set. Or maybe I feel that the default should be that your domain
logic/model should decide if your code should fail miserably, and not the
persistence.
I think annotation systems on top of Neo4j, like jo4neo, could be a good
place for handling things on this
Exactly. You would/could create a chicken and egg problem if the
service dependencies needed to be known prior to a recovery or startup
options, and since you can't start the db, you couldn't read the
metadata.
The separate file approach (or even a mini db that used
Neo
The other very useful aspect of the default value method is that is
allow resilience of applications that may have had data or objects
persisted into Neo but that have since had additional properties added
to their domain model. The default value approach helps mitigate the
need
Traditional migrations tend to be a one time event, rather than an ongoing
process. The risk of a lazy approach is that the db could be logically
inconsistent at certain points. I guess the short answer is the ubiquitous it
depends
-Original Message-
From: Peter Neubauer
jo4neo looks veeery interesting. It's passed by my eyes before, but now that
I looked a bit closer at it I see that I'll have to try it out :) Thanks!
/ma
2010/1/5 Anders Nawroth and...@neotechnology.com
Hi!
Mattias Ask:
that isn't set. Or maybe I feel that the default should be that your
Hi folks,
it would be great to keep track of all the cool projects that Neo4j
gets used in, as far as they are public. Both for others to find
potential projects that do stuff in the same domain or solve
interesting problems, and for everyone to get a feeling of what Neo4j
can be used for.
So, in
11 matches
Mail list logo
