[PEAK] peak.model & peak.storage viability?

[Erik Rose]

Phillip et al,

How insane would I be to use peak.model and peak.storage in a new 
project, given the peak.query stuff coming down the road? 7 months ago, 
you answered at least half this question for John Landahl...

On Jul 9, 2004, at 11:08 AM, Phillip J. Eby wrote:
>> peak.model: You didn't get into specifics here, but mention the 
>> possibility of
>> destabilizing changes.  Since changes to the model layer of an 
>> application
>> can have far-reaching affects throughout the application's code, I'd 
>> like to
>> hear a lot more about what you have in mind here.  Do you have 
>> specific
>> changes in mind?  How safe is it to continue using peak.model as it 
>> is today?
>
> Primarily, I'm thinking about changes to the persistence mechanism, 
> internal attribute representation machinery, event/validation 
> machinery, and maybe the "method exporter" subsystem of peak.model.  
> I'm not really looking at changing the surface APIs, which I'd like to 
> disturb as little as possible.
>
> So, if you're just defining metadata or methods you might not even 
> notice that anything's changing.  But if you're doing certain kinds of 
> validation hooks or digging deep into the feature framework, there 
> might be some changes.

...but it's been awhile, so I thought I'd check that this is still true 
before I bet the farm.

I'd likely base my solution on Ulrich Eck's sqldm package (posted here 
on 10/10/2003), which provides SQL-specific subclasses of EntityDM and 
QueryDM. They do reference _p_oid and _p_jar but not so much that I 
fear being unable to fix them when the underlying persistence machinery 
does change.

I heartily appreciate your thoughts.

Erik