ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Neo4j Exceptions

As protocols, APIs are an extremely important part of the product and in case you have a rich API you might face criticism:

Now if a DeadlockDetectedException, HaCommunicationException, NotFoundException(thrown if a request is made to a node, relationship or property that does not exist), NotInTransactionException, ReadOnlyIndexException or TransactionFailureException were thrown, what would I really do about it? Nothing much, unfortunately. There is no way I could be smart and recover from these. At the most I’d log it and re-throw it.

A while back I had my part of suggestions related to Neo4j API and some of those became part of the Neo4j 1.2 roadmap. Problem is not that API is not fixable, but if you want to maintain backward compatibility things are quickly becoming complicated (or leading to ugly APIs).

Update: I’ve received a couple of comments that made me realize that most probably I haven’t expressed myself too well. So here is another attempt:

  1. it is normal for graph databases (and embedded databases) to have richer APIs. That’s why I’ve suggested to some of the graph databases to look more into providing it as a service, as that would reduce a bit the complexity
  2. it is normal that a complex API would not always be obvious and perfect to everybody
  3. it is great to get feedback about your API (in whatever form it comes, from “your API sucks” to “it’s good, but I’d like to be able to do this and that”) as it means that:
    • your users are getting deeper into your product and they care about it
    • you’ll have a chance to improve it over time so new users will find a better API
  4. maintaining backward compatibility for complex APIs is always a challenge and you must think about this as early as possible so you can follow the same policy over time

Original title and link: Neo4j Exceptions (NoSQL databases © myNoSQL)

via: http://thought-bytes.blogspot.com/2010/12/runtimeexceptions-and-neo4j.html