The Old Joel on Software Forum: Part 4 (of 5) - Impedance Mismatch Follow-up/Proposal

Impedance Mismatch Follow-up/Proposal

Solving the Impedance Mismatch between Programming Languages and Databases
(A Proposal by Example in Java)

Note: This is a follow-up to http://joelonsoftware.com/items/2004/03/25.html. This is a suggested fundamental change to the Java language for the purposes of discussion. In short, the strategic use of the keyword "persistent" defines the data store interaction.

Proposal:
Object-oriented design rests on the foundation of many principles, including the standard concepts of "encapsulation, inheritance, and polymorphism." Somehow, though, we’ve managed to overlook the most important and fundamental concept of objects: persistence. When required, object persistence should occur automatically, without the developer’s intervention. This persistence must transparently cross the boundaries of time and location and must be a native feature of the language.

// define a persistent class
public persistent class Employee() {
// some primary key is required
private primary key int id;
private String first;
private String last;
private String type;
. . .
public Employee(int id) {…}
// getters and setters follow
. . .
}

// reference a persistent object
{
. . .
Employee emp = new persistent Employee(1);
// if the employee exists in the data store
// the employee object will be created with all attributes
// if the employee does not exist in the data store
// they do now
. . .
}

// reference a collection of persistent objects
{
. . .
Collection employees = new persistent Collection(Employee.class);
// employees now contains all employees from data store
. . .
employees.setLast("M*");
// employees now contains all employees with last name starting with "M"
. . .
employees = new persistent Collection(Employee.class);
employees.setType("Full" || "Part");
// employees now contains all full and part-time employees
. . .
}

// run a session with the data store
{
. . .
Employee emp = new persistent Employee(1);
session {
emp.setFirst("Bill");
emp.setLast("Smith");
System.out.println("Success!");
}
catch (DataStoreException dse) {
System.out.println("Error!");
}
. . .
}

// delete an object from the data store
{
. . .
Employee emp = new persistent Employee(1);
emp = persistent null;
. . .
}

// delete all Bill’s from the data store
{
. . .
Collection employees = new persistent Collection(Employee.class);
employees.setFirst("Bill");
employees = persistent null;
. . .
}

Some things this proposal doesn’t address:
* Location of data store (make it a run-time option)
* Implementation of data store (who cares)
* Data store performance (solved by vendor competition)
* Accessing data store from other languages/tools
* Multi-user/JVM access to data store

?
Thursday, May 13, 2004

Corrected URL, without the period:

http://joelonsoftware.com/items/2004/03/25.html

?
Thursday, May 13, 2004

Interesting use of the try/catch model for implementing trasactions.

I don't think the primary key is something that should be managed explicitly as such -- after all, objects already have an id associated with them: their memory address! At the very least, the id is something that can be managed for us.

While it is all very well and nice to have this stuff happen automatically, the fact is you don't want the same functionality for every data store.

Also, I don't think it is necessary to have extensions added to the language for the purpose of serializing objects to a relational database -- that can be solved nicely just using reflection (assuming the language in question has good reflection capabilities)

Daniel Martin
Thursday, May 13, 2004

"I don't think the primary key is something that should be managed explicitly"

This would be the means by which *we* would retrieve the record later. In other words, it is the way we reliably get back to employee "John Smith" between sessions.

You are correct that the data store should manage a "real" primary key. One we don't care about. Note, though, that instantiating two employee objects with the same primary key would just create two references to the same instance.

"you don't want the same functionality for every data store."

What functionality would differ?

"Also, I don't think it is necessary to have extensions added to the language for the purpose of serializing objects to a relational database -- that can be solved nicely just using reflection (assuming the language in question has good reflection capabilities)"

But techniques using reflection would require active data-store coding. DataStore.save(), .load(), DataStore.foo(), etc. Extending the language removes that requirement. The data store vendor *will* probably use reflection to serialize the object.

Who's to say it will go into a relational DB?

?
Thursday, May 13, 2004

As much as I hate to parrot this, Pascal is right:
http://searchdatabase.techtarget.com/tip/1,289483,sid13_gci821252,00.html?FromTaxonomy=/pr/284872

http://searchdatabase.techtarget.com/tip/1,289483,sid13_gci828701,00.html?FromTaxonomy=/pr/284872

Basically, [Oracle, Microsoft, etc. should] implement a proper RDBMS and there *is* no "impedance mismatch".

MR
Thursday, May 13, 2004

Paper I'm currently reading which might be interesting :

http://www.research.microsoft.com/~emeijer/Papers/XML2003/xml2003.html

phil jones
Thursday, May 13, 2004

MR -
I don't sign up with websites just to read articles. Can you summarize?

phil jones -
XML != DB. How does this address the mismatch? Native XML support does not make persistence transparent.

?
Thursday, May 13, 2004

I think that's interesting, but why do you have to specify the persistent keyword all the time ?

Wouldn't it be better to decorate the class and/or it's members and then let the infrastructure take care of everything else. You could use Attributes (c.f. .NET).

Steve Jones (UK)
Thursday, May 13, 2004

What you really want are first-class table types.

Thursday, May 13, 2004

Steve-

Possibly... But I assume the developer might want to create a temporary instance without it showing up in the data store.

?
Thursday, May 13, 2004

? -

Over the last 25 years, I've seen about a dozen projects that tried to do almost exactly what you're suggesting. Projects that persisted their data in an object-oriented database enjoyed some modest success. However, every last one that tried to use a relational database underneath failed.

So, before repeating history it will be useful to examine previous attempts and understand why they failed.

Also, if you think that OODB's are the savior, remember that most of the world's structured data is in relational databases, so an OODB is only useful for an app where the data doesn't exist yet.

Jim Lyon
Friday, May 14, 2004

"But I assume the developer might want to create a temporary instance without it showing up in the data store"

Why should it matter ? If the answer is perfermance, then flip the choice, so you have to specify non-persistant and leave the default (i.e. when you don't specify anything) to be saved.

I think that's better. After all, the whole premise of this system is that it saves stuff to the database and it'd be pretty ironic if the default behaviour was not to save it.

As an aside, have you seen InterSystems Cache ? It does a lot of interesting OO persistance, using a sparse array-based system. Check them out:

http://www.intersystems.com/

Steve Jones (UK)
Friday, May 14, 2004

Jim -

You'll notice in the proposal that I did not specify the type of data store (OO, relational, etc.). This proposes a change to the language specification.

Let vendors compete to provide a competitive implementation. If Oracle can efficiently meet the spec *and* provide access to the data using a relational model... If InterSystems can meet the spec and provide the most adapters...

?
Friday, May 14, 2004