Thanks for the prompt and thoughtful response, comments below... - Dexter
> 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 This is an excellent insight. I'll have to review with my team to see if we might have done this, but this is the kind of "roadmap" / best practices documentation that would be wonderful to make more prominent. I'll go back and see if I can find this in the documentation, but your advice raises the following questions: Is it *always* a bad idea to mix the two models? Or just within one transaction? What about cases where different parts of a multi module application use the same DB? Is it only bad in the context of writes? Or are queries problematic? > - Operations against Graph are non transactional > > If you can find that the problem is in OrientDB, please let us know to fix it > asap. Thanks, as I said before, we appreciate your responsiveness and obvious hard work on this system > > 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. Great, I'm very happy to hear that 2.0 is focused on reliability & stability. > > 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) > > More good news - we will start using the lucene plugin shortly > 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/. > Thanks, will check it out > 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 > [email protected] - [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. -- --- 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.
