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 <peter.neuba...@neotechnology.com>
Date: Tue, 5 Jan 2010 14:13:36
To: Neo user discussions<user@lists.neo4j.org>
Subject: Re: [Neo] getProperty and null...
Hi there,
yes, default values are nice, but I think in the case of resilience,
this should be handled in a more generic approach outside of the core
engine, dealing with the whole space of default values and lazy
migrators of nodes and relationships ("migrators" being plugins to
handle more complex scenarios than returning a default value, e.g.
adding or removing props/relationships), maybe attached to the
neo-meta component that can assign "node schema migrators" between
versions of the meta model.
WDYT?
Cheers,
/peter neubauer
COO and Sales, Neo Technology
GTalk: neubauer.peter
Skype peter.neubauer
Phone +46 704 106975
LinkedIn http://www.linkedin.com/in/neubauer
Twitter http://twitter.com/peterneubauer
http://www.neo4j.org - Relationships count.
http://gremlin.tinkerpop.com - PageRank in 2 lines of code.
http://www.linkedprocess.org - Computing at LinkedData scale.
On Tue, Jan 5, 2010 at 2:09 PM, <rick.bullo...@burningskysoftware.com> wrote:
> 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 for a traditional "migration" process.
>
>
>
> -------- Original Message --------
> Subject: Re: [Neo] getProperty and null...
> From: Mattias Persson <matt...@neotechnology.com>
> Date: Tue, January 05, 2010 4:59 am
> To: Neo user discussions <user@lists.neo4j.org>
> 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 me... it should just return my value or else fail miserably
> so that I can see right then and there that there's a bug in my code
> (in this case the code which created my domain object or similar).
> And the one with the default value is great since I find myself
> passing in other things as well, not just null. I just couldn't live
> without any of them really.
> Just my point of view on this...
> 2010/1/5 Mattias Ask <mattias....@jayway.com>:
> > 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 have to check for
> org.neo4j.api.core.
> > NotFoundException everywhere that I read properties that are not
> mandatory.
> > What if myNode.getProperty(SOME_PROP) was to return null instead? The
> doc
> > says explicitly that you can't persist null. If
> > myNode.getProperty(SOME_PROP) where to return null this would mean,
> without
> > any doubt, that the property does not exist, right? The upside to
> this would
> > be that I wouldn't have to use the DefaultReturnValue null
> everywhere. And
> > the argument that I'd have to null-check everywhere is kind of moot
> since I
> > already return null as DefaultReturnValue.
> >
> > In my case my domain objects extend a NodeDelegate, which takes an
> > underlaying node in the constructor. This means that I can use
> > getProperty(SOME_PROP, null) everytime I call
> getProperty(SOME_PROP)... but
> > the question is if there are any downsides to doing that? What are
> your
> > thoughts on this?
> >
> > Best,
> > Mattias Ask
> >_______________________________________________
> > Neo mailing list
> > User@lists.neo4j.org
> > [1]https://lists.neo4j.org/mailman/listinfo/user
> >
> --
> Mattias Persson, [matt...@neotechnology.com]
> Neo Technology, [2]www.neotechnology.com
> _______________________________________________
> Neo mailing list
> User@lists.neo4j.org
> [3]https://lists.neo4j.org/mailman/listinfo/user
>
> References
>
> 1. https://lists.neo4j.org/mailman/listinfo/user
> 2. http://www.neotechnology.com/
> 3. https://lists.neo4j.org/mailman/listinfo/user
>_______________________________________________
> Neo mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
_______________________________________________
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
_______________________________________________
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
