First things first, Alan ditched the microphone - he has a big voice.

Alan was the chief architect for TOPLink back at The Object People. Now he does GLORP, an open source O/R mapping framework.

This talk isn't about the intro, this is about the harder issues and complex things you do with GLORP.

Interesting issues with GLORP: Reading, Mapping, Caching, Writing.

GLORP: Generic lightweight object-relational Persistence Open-source: LGPL(S) - the (S) is the "What it means in Smalltalk" according to the author (Alan). Portable: Lots of databases, lots of Smalltalk dialects (VW, Dolphin, VA, Squeak, Object Studio)

Architecture: Non-Intrusive for the Database and the Object Model. Shouldn't have to make changes to the DB or your classes to make them interact. Metadata-driven for table descriptions Transactional: Object-level commit/rollback. No explicit "Write this object out now". Instead, start a Unit of Work, do stuff, commit. Queries are expressed as Smalltalk objects/blocks. Dynamic SQL generated at runtime. Multiple sessions simultaneously, one broker per session.

Model: 3-layers: ClassModel, DatabaseModel, Descriptor ("glue") [mappings, joins] Class model includes types Table model includes foreign key constraints, optional indexes Queries Commands Unit of work

Read Issues: Complex queries Complex mappings Reporting/non-object data - don't really want to read a bunch of objects Bringing back multiple things at once - avoid round trips, a bottle neck. Can't read objects one at a time.

Horizontal case: Following join relationships if you ask it too, for one read to fill out a table. #alsoFetch: and #retrieve: q := Query read: Customer. q alsoFetch: #address. q alsoFetch: [:cust | cust address region].

Retrieve is the same as alsoFetch. The result of retrieve brings back the objects you asked for WITH the other data it grabbed. alsoFetch just builds up the objects like normal - it doesn't put the address in a proxy on the customer, it puts the address directly on the customer [Q: that means the caching policy can't let go of it later? A: yes, that'd be a bells and whistles thing]

Complication: suppose a customer has no region, SQL will omit the entire row for the customer. To avoid this, you need to do an outerJoin: q alsoFetch: [:cust | cust address region asOuterJoin] This can happen even if we just order by an attribute of a possibly missing object. [Q: isn't outerjoin the common case? A: possibly, easy to change, might help people make less mistakes]

Vertical case: Suppose our report table has a "total orders" column. This is a complicate calculation. q alsoFetch: [:each | each orders] But.. get duplication of data, can become large. (Nelson is Alan's dog). The Datbase will be sending back the same data because of the join. This can become very expensive. (Not explained how to deal with that!)

Non-Object Data: Suppose we don't need the real objects, such as counts etc. #retrieve: allows "primitives". q := Query read: Customer. q retrieve: [:each | each name]. q retrieve: [:each | each address street]. q retrieve: [:each | each salesREgion asOuterJoin name]. This gets you just raw data: #( 'Alan' '55 Merchant st.' 'Canada (East)') [Q: how do you know which column is what? A: no help, it's the order you specified] [Q: can you ask the query for the columns? A: yes, might be slightly tricky to get it back in a form that's useful..]

Aggregate and other functions: Some data may not make sense in objects: q retrieve: [:each | each salesRegion name count]. r retrieve: [:eachj | each countStar]. s retrieve: [:each | each versionNumber max]. t retrieve: [:each | each orders amount sum]. Other data may be converted: q retrieve: [:each | each name asUppercase]. Also shrtcut syntax: q retrieveMax: #timestamp There is currently no group-by

[Q: where's the best place to read up on these options? A: Uhm, there's some blog entries? No doco really.. some doc on the website, but only basic stuff] [Q: how do you tell the difference between the shortcut and a complex statement, how do you tell the difference between sending #sum or doing a summation? A: you don't know the difference. Essencially, #sum is a reserved word. You can't get at it if your object has an attribute called #sum. SQL functions take precedence]

Filtered reads: q read: Customer where: [:each | each sticBoardMember = 'T']

[Q: is there abstract class types. A: conditional mappings, can use this to swap the kind of object it'll make. Inheritence support replaces abstract class types against a column]

If you're not sure you need the addresses, so only read the customers first, then if you ask any of them for an address, it'll go get all the addresses. Second query is not using primaryKey in's, it's redoing the real query (fast for DB's, so long as it's not too complex) This does two queries, first query then second for addresses. This approach reduces the bandwidth required by a full join. To do it, you say 'customerMapping useFilteredRead' instead of using alsoFetch:

[Q: how does this interact with a weak caching policy, won't things go away? A: I don't know, good question. I suspect the query proxy will have a strong collection. That's a guess, I'd need to check it]

Cache: For performance, but also for object identity. The amount of cached data can become a problem. Pluggable cache policies: keep forever, weakly referenced (only VW at this point), timed expiry

[Q: when would you still write SQL? A: when either doesn't make sense insense of the SQL mapping, or stuff that is too complex for the mapping to handle]

[Q: are constraints mapped? and if you wipe one thing will it wipe the other thing that relies on it? A: yes mapped, no not auto-deleted. Good thing to have, but don't have it]

[Q: At which time would you recommend commercial projects to be based on GLORP? When should people move to GLORP? A: Tolerence for bleeding edge. No migration plans from other frameworks. For LENS there will be, for Toplink there probably will be. If you want to write descriptors in code and not have documentations, yes, you can use it now. Cincom hasn't officially said GLORP has replaced LENS. 2 years down the road it should be a full supported product. There are SUnit tests, they mostly even pass]