Re^5: Maybe database tables aren't such great "objects," after all ...

It still seems to me that sometimes you'd want to operate on a number of objects inside a single transaction and other times in different transactions.

This would expose the nature of the underlying database at a high level if you were to explicitly commit at a high level.

I think ELISHEVA makes a good point. To design these things, you'd need someone with excellent DB and Object knowledge, but I'm wondering if you might also need that kind of knowledge to use the Objects effectively.

Update: I'm probably talking nonsense here. I can't really think of where you wouldn't want to encapsulate the commits with the updates, although perhaps you could get some efficiencies by deferring them across object references. That could be built into the toolkit, too, if you were clever.

Comment on Re^5: Maybe database tables aren't such great "objects," after all ...

Replies are listed 'Best First'.
Re^6: Maybe database tables aren't such great "objects," after all ... by DStaal (Chaplain) on Mar 28, 2011 at 19:11 UTC
It still seems to me that sometimes you'd want to operate on a number of objects inside a single transaction and other times in different transactions. Yes you will. And sometimes that will mean you change a single record in a single table, and sometimes that will mean you'll change a dozen records in a dozen tables. My statement and yours do not map to each other. Stop thinking of data in the database as 'objects'. It's not. It's data. It knows nothing about what code should operate on it. Organize it based on it being data, in the best form to store and retrieve it. And code your objects to get their data (possibly through some database API of some sort) from the data store and use it in the most effective way for the program. Write the API to handle transferring it in a way that's not visible to the (object) programmer. Then maybe you'll stop getting hung up on the idea that you are storing your objects in a database. Will there be limits? All this is abstraction. Eventually the data is being stored as a series of bits. Eventually the program is being run as imperative assembly code. Stress the abstractions hard enough, you'll run into places where they can't hide what they are abstracting. That's the nature of abstractions. But don't start confusing one layer of abstraction in one domain with a different layer of abstraction in a different domain just because they are both abstractions.	[reply]

Replies are listed 'Best First'.

Re^6: Maybe database tables aren't such great "objects," after all ...
by DStaal (Chaplain) on Mar 28, 2011 at 19:11 UTC

It still seems to me that sometimes you'd want to operate on a number of objects inside a single transaction and other times in different transactions.

Yes you will. And sometimes that will mean you change a single record in a single table, and sometimes that will mean you'll change a dozen records in a dozen tables. My statement and yours do not map to each other.

Stop thinking of data in the database as 'objects'. It's not. It's data. It knows nothing about what code should operate on it. Organize it based on it being data, in the best form to store and retrieve it.

And code your objects to get their data (possibly through some database API of some sort) from the data store and use it in the most effective way for the program. Write the API to handle transferring it in a way that's not visible to the (object) programmer.

Then maybe you'll stop getting hung up on the idea that you are storing your objects in a database.

Will there be limits? All this is abstraction. Eventually the data is being stored as a series of bits. Eventually the program is being run as imperative assembly code. Stress the abstractions hard enough, you'll run into places where they can't hide what they are abstracting. That's the nature of abstractions. But don't start confusing one layer of abstraction in one domain with a different layer of abstraction in a different domain just because they are both abstractions.

[reply]