Hi Dexter,
> Hi Luca, > > I’d like to add my voice to the need for improved documentation. > > An example of stability concerns was a recent episode using 1.7.7 where we > found that a *small percentage of edges* that we were creating in one of > our loaders were only in one direction, could not be traversed in the other > direction. We were going to report the problem and provide a code example - > *but > then the problem disappeared and was not reproducible*. We are left with > a vague fear that the problem would recur and compromise our users data. > Its certainly possible that this is our bug in the sense that we may be > using the graph or document model incorrectly, but I’m concerned that we > were able to provoke a behavior using low-level graph model operations that > was 99% successful rather than either working or failing. We apparently ran > into some edge case but we have no idea what the cause of the problem was > or why it went away. > We usually see such problems in 2 cases: - Graph and Document API are used together - Operations against Graph are non transactional If you can find that the problem is in OrientDB, please let us know to fix it asap. > While reading the dialog on this google group, I have been very impressed > with your rapid response to bugs and questions. > > On the other hand, I’m worried that you and your team may be too > responsive to requests for features - you have a fundamentally strong > product but it can be compromised by spreading your efforts too broadly. > (I’m sympathetic to the problem - our project faces the same feature vs. > robustness tradeoffs as we come up to our v1.0 release) > > So I would like to put in a vote for a very solid, well-documented core > OrientDB - and a release that we can commit to for a fairly long time if we > limit ourselves to that core functionality. > This is what most of the users asked us, and this is the reason why we're working hard to provide an always more efficient, fast and reliable engine with OrientDB 2.0. We've also started to rewrite our SQL engine to be more strict avoiding weird corner cases with some syntax. This will be ready in 2.1. All the last new components are configured as external plugins. Take a look at: - OrientDB-Lucene (https://github.com/orientechnologies/orientdb-lucene) and - OrientDB-ETL (https://github.com/orientechnologies/orientdb-etl/wiki) > From the perspective of the NDEx project, here’s a cut at our top > priorities for OrientDB: > *(I understand that some of these issues are currently addressed. I’m > enumerating our priorities, not making a list of implicit complaints :-) )* > > - Robust operation of the Graph Model and Document Model > - Especially the reliability and correctness of stored content, > methods for verifying correctness and consistency of database. > - Documentation and executable Java code examples for Graph and > Document Model use > - Schema management > - Best practices for efficient queries and inserts > - Use of transactions > - Large inserts - when and why to turn off transactions, best > practices to be robust without transactions. > - Best practices for indexing > - Including Lucene > - Documentation and code examples for use of OrientDB in embedded > vs remote mode > - Connection pool management > - Documentation and script examples showing best practices for > maintenance of production databases > - backup and restore > - strategies for recovery in cases of corrupted data > - replication > - migration between DB versions > - Clear separation of base Graph and Document Model usage > documentation from higher level abstractions. > - we need simplicity, maintainability, and performance. > - Tinkerpop is cool, but the use of that option and the additional > mental and computational overhead should be a very distinct choice. > > Thanks for the list! Improving the documentation is on our todo-list, any suggestions like yours is welcome. > > In the future, we will also be interested in scalabilty, distributed > servers. But these are only of concern if the our single processor server > is solid. > > Orient is of course a for-profit company. If some utilities / support > packages aimed at production databases were part of the enterprise edition > or support contracts, I’d be happy to hear more about it. > OrientDB is an Open Source project, so it's non-profit. But Orient Technologies was created to give professional support to the Open product. We have two support plans: Development and Production. Take a look at: http://www.orientechnologies.com/support/. With both the supports you'd have a private channel with OrientDB committers to help your team to fix problems and to validate the way OrientDB has been used. Lvc@ > > Dexter > > Dexter Pratt > Director, NDEx project > Ideker Lab UCSD / Cytoscape Consortium > dexterpratt.bio@g <[email protected]>mail.com - [email protected] > www.ndexbio.org > > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
