Discussions

News: NeoDatis pays 10$ for each bug found in its object database

  1. The 1.9 release of the java version of NeoDatis ODB is now in RC4 stage. The final release is coming soon. But before we put the tag as a final version, we would like to get more feedbacks from the community, running one more test "game", and we are calling this kind of test, a "Community Test". The idea behind "Community Test" is simple, just asking for you to run and analyze Neodatis ODB against your application scenario, your use cases, and if you come across with some bug, report it. There aren't rules for the tests, the focus is really finding bugs as they popup in your application (if they really exist :))! Trying to spread this idea on the community, the Neodatis is now creating the 'Zero Bug NeoDatis Campaign'. This initiative came after a long talk between NeoDatis and some users that have been making donations for us, so if we receive some money from the "Community", why not invest it back to the Community? And the only focus here, is just to improve more and more the Neodatis ODB. The goal of the campaign is to incentivize/motivate NeoDatis users to register any 'surviving bugs' of the current release before tagging it as final. During this campaign, NeoDatis will pay $10 per bug to the first ten registered bugs on Source Forge, but of course, you should register as many as you find. Go to http://www.neodatis.org/1-9-zero-bug-campaign for more information
  2. Hi Olivier, do existing bugs that I already raised count ? ;-) e.g 2049624, 2033784. If either of those count then you can pay me the $10 and I'll donate it back to Neodatis :-) Nice idea though
  3. Hi Andy! I know you contributed and I thank you very much! But you know we can't do that. If we do that for you, we must do it for everybody! Anyway, thanks for the support.
  4. Object databases are not that popular, but IMHO these databases may be used under new incarnations. They might be the technology beyond: - cache, distributed or not (the previous Gemstone app server used the Gemstone object database for the data cache into the middle tier), - data grid, - javaspace and javaspace extension (I noted one GigaSpaces whitepaper talks about EJB/JPA implementation for a javaspace extension), - and beyond javaspace, Space-based architecture, - etc. What do you think ? Thanks. Dominique http://www.jroller.com/dmdevito
  5. sql tools[ Go to top ]

    The biggest problem with object databases is the bewildering inability of object database vendors to produce an sql interface so that your db admin tools could work naturally with it. It really is such a simple solution. In this way you please the db admins and yet provide an accessible object oriented interface to the app developer. Many more people will start using them forgetting what engine is behind doing the job. Especially for smaller projects. Can anyone explain to me why these db vendors don't get it? Does anyone need to tell them? All the effort that was put behind the rdbms to achieve scalability and redundancy can be put into an object database just as well with possible similar results. Do this and you'll kill MySql and the like for most web projects.
  6. Re: sql tools[ Go to top ]

    The biggest problem with object databases is the bewildering inability of object database vendors to produce an sql interface so that your db admin tools could work naturally with it.
    (1) while JDO spec is seen as object-database-oriented, note that JDO repository may be requested with SQL too. I read here: Sometimes an object-based query language (such as JDOQL) is considered not suitable, maybe due to the lack of familiarity of the application developer with such a query language. In this case it is desirable to query using SQL. JDO 2 standardises this as a valid query mechanism, and JPOX supports this (2) But the main point is you missed IMHO the new incarnations of object databases. In fact, you could use object databases while using also SQL, because you have more and more in your architecture, an object database with a SQL database: - object database-or-similar: cache, grid, javaspaces, SBA... - SQL database: whatever RDMS database you have in mind.
    you please the db admins and yet provide an accessible object oriented interface to the app developer.
    Exactly, you could please both sides, because you already have sometimes both technologies (see above). What I wonder is: are object databases going to live only under these new incarnations, under these new names, or, are they going to be a bit more recognized.
  7. Re: sql tools[ Go to top ]

    Hi Florin, The Versant Object Database provides an odbc/jdbc bridge tool called VSQL( reVind ) so that you can use standard reporting tools like CrystalReports. We've had this tool for about 7 years. Also planning on a native jdbc driver which will work better with our larger databases .... >500G. On the db4o side, DataNucleus provides SQL type access over db4o. I do agree with you. There are two issues. (1) Application development API's without the pain of mapping, providing the excellent performance and scalability. (2) Unplanned access for reports or tweaking things that inevitably come up in the real world. It is worth pointing out.... the largest area of spending in data management in 2007 and forward is on data warehousing. Increasingly, there is just too much data and reporting off of production databases becomes and issue. So, to the extent you can export into these tools, reporting becomes less an issue. Right tool for the job, -Robert
  8. Thanks[ Go to top ]

    Interesting. I'll check them both.
  9. If everybody thinks that an sql interface (using jdbc for example) is the most important thing that lacks object databases we are ready to implement it. As Dominique (http://www.jroller.com/dmdevito) describes in its post about FDD (Funding Driven Development), would anybody/any company like to (partially) fund this feature?
  10. If everybody thinks that an sql interface (using jdbc for example) is the most important thing that lacks object databases we are ready to implement it.
    Well, IMHO, depending on how you want to sell your object database, you need different features: (a) BI: you need a SQL request mechanism in order to integrate with most current reporting tools, (b) cache/data grid: you need distributed instance XA-like synchronization (similarly to JBoss POJO Cache or Coherence ?), with provisioning mechanism to populate easier the cache/grid, (c) SBA (Space-Based Architecture): promote NeoDatis in the middle tiers with its own persistent mechanism, develop a (potentially asynchronous) synchronization mechanism in relation to a SQL RDBMS into the back-end, with provisioning mechanism to populate easier the "space" (d) etc. And there are relationships: - if you choose (c), you don't need (a). - (b) and (c) share an (optional?) provisioning mechanism - etc. Dominique
  11. If everybody thinks that an sql interface (using jdbc for example) is the most important thing that lacks object databases we are ready to implement it
    DataNucleus already provides an SQL interface to db4o in case its of use --Andy DataNucleus