William Cook, Moderator: I've been a programmer for a long time and I'm not sure I trust myself with the data -- so it's a little scary.
We have a couple of questions [from the audience] here.
Basically there's a question: "What is happening with ODJ?" I just want to elaborate on this a little more, this is the latest in the long line of standards for accessing relational databases starting with ODBC and we've got to have more acronyms and standards and proposal in that spaced than in any other space I know. There's something clearly going on here, we're having a new proposal every year or two, right? How many of these: JDO, EJB-this EJB-that, the .NET versions of this stuff, what's going on here? Is this ever going to end? It's roughly the question I have so if the people here involved in that can answer that.
Robert Greene, Versant: I just have one question to your statement which is that you're not comfortable with the data but are you comfortable with your models because I think that goes back to what Christof was talking about, taking control again of the models and thinking from a domain driven perspective and not having to worry about what's going on with the data, how it's stored is part of that model, but: Be comfortable with your model.
William Cook, Moderator: That sounds good to me.
Patrick Linskey, BEA: Regarding the question of the audience I think that there are a lot of acronyms out there and in the defence of the persistence role: The web services world has even more.
William Cook, Moderator: They're not replacing their previous ones they are adding more of them. But in the relational world they are always replacing the previous one.
Patrick Linskey, BEA: That's true we do like to reinvent the wheel in the OR mapping world. I really hope that the standards in the OR mapping world settle down over time, because I think that the key thing, a good OR mapping standard, and a good object database API and a good LDAP API for storing objects in an LDAP server all end up looking a lot the same. You can do conversions between the different APIs with an easy set script. So it's in the best interest of everybody, except for the vendors, for there to be strong and adopted standards for in whatever form they get delivered for how you access data as objects. Because this is a problem that a lot of different people solve. Here's my way of accessing data as objects and the users of all these products are the ones that benefit from having a common API on top of them. Having extensions to APIs is fine but having some basic subset is really something that, any vendor that says something is not deliverable is trying to lock you into their product -- and that is not nice.
Christof Wittig, db4objects: I wanted to speak to one of the initiatives of William Cook himself, you may not know that he is the author of the safe queries concept, among others.
We have implemented that in our database as native queries and basically it makes the program language be Java or .NET itself the query language. It's totally native, it's type safe, it's object oriented, and it's fully optimized. That is one way to reclaim the territory, we don't speak the other language of the DBA guys. SQL was written for end users, not for programmers. We use our language because we're better in that. No one can be perfect in two languages at the same time -- no matter how good you are. So one standard is: Let's take our language standards and just use it, for querying for instance and for persistence tasks. So: no new standard please.
Bob Walker, Gemstone Systems: I want to second what Christof just said. I think having to deal with two different languages is part of the core of the difference that we run into in mapping objects into relational data. Our effort at Gemstone has to be try and keep it in a single language. So your queries are Java, your queries are Smalltalk. There's been an effort, ODMG 3.0 with the definition of OQL to define a standard object query language. This is something that would behove all of us as vendors to take a look at and participate.
