View Single Post
Old 02-16-07, 05:31 PM   #64
rhink
Registered User
 
Join Date: Jul 2005
Posts: 434
Default Re: Languages you know

Quote:
Originally Posted by evilghost
It's fairly easy to find someone who doesn't know what they're doing; I used to love the developers who would "SELECT * FROM [tablename]" and load it into a control and enumerate the entire recordset/control looking for the selected choice instead of just including a WHERE clause in the SQL statement.
Heh. I'm using an implementation of Java Data Objects (aka JDO) for a project I'm working on. It's supposed to transparently map your data objects into the database, handle persistence for you, you create queries based on your objects, it maps it into SQL, etc. One (among many) of the major issues with it is that people see an object in java, they tend to treat it like one, even if that object is transactional and everything you do with it generates a query that hits the database. So something like:

Transaction txn = new Transaction();
txn.begin();

/* Set up query somewhere in here */
Collection result = query.execute();
Iterator iterator = result.iterator();
while(iterator.hasNext()) {
//iterate it!
}
txn.commit();

seems quite reasonable in java, but of course what's really going on is it's sending a SELECT FOR UPDATE statement for a single row to the database at very high frequency. People love to do it though, just to pick out one or a small handful of records, mostly because JDO's query interface can be somewhat painful for the uninitiated. Even when the resulting iterator could contain literally hundreds of thousands of results. Then people wonder why things are god awful slow, why we get a zillion transactional/record locking type errors from the database, etc. And that's not even getting into the massive amounts of trash this type of approach generates on the heap...

I've spent huge amounts of time cleaning up that kinda **** in performance critical sections, and re-writing portions of our infrastructure to make it less necessary to go to the database (caching more stuff locally, people can just load it out of the cache, etc).

It's not always people that are bad coders doing this kind of thing, either. People just don't necessarily think about what's going on under the covers when you use a product like JDO. For that reason, I don't think that higher levels of abstraction and implementation hiding are necessarily a good thing. Sometimes things should be slightly painful, and map more closely to the implementation, just so the coder is forced to think a little more about what they're doing.
rhink is offline   Reply With Quote