Renamed state ?ForRelations() to _other ?StateForRow(), made it private, and stopped passing it a state dict.Brought _oid ?ForElement() (renamed from oid ?ForElement()) to the top level of its class so it can be overridden.EntityDM no longer blows up if you don't have any read ?OnlyFields.However, if anybody can answer the questions by the XXXs and TODOs, I'm all ears! I'm not much interested (yet) in comments on the implementation, which is still as ugly as sin and will improve gradually. I have to go learn that, though, before I say more.)

Does anybody actually use SQLQueryDM? (I don't think it adds much value.) Are there useful cases my design is too brittle to support? (Do note the changes to the API I've already planned: do a case-sensitive grep for 'Field'.) (Okay, never mind that 'Field' stuff now, from ?PhillipEby's prompting, I'm thinking about scrapping the whole fields attribute and using tadata somehow instead. I'm also still interested in comments on the API. I still intend to have a Trac+svn set up for this someplace before long I'll post a link when I do. As always, this code has no warranty and no guarantees. I have a dozen SQLEntityDM subclasses (with more on the way) to maintain now, so future changes will be considered with commensurate gravity. In addition, the API should be pretty stable (until the model metadata metamorphosis (explained below) if it happens). SQLEntityDM and SQLQueryDM work: inserting rows, deleting them, and updating them are all hit by my production code. It's based on peak.storage and peak.model and is an evolution of some code Ulrich Eck posted to the mailing list. It's an object-relational mapper for use with SQL DB's.

Sqldm