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

[Phillip J. Eby]

At 01:15 PM 4/29/05 -0400, Erik Rose wrote:
>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...
>
>...but it's been awhile, so I thought I'd check that this is still true 
>before I bet the farm.

What's changed is that I no longer plan to refactor peak.model and storage 
directly.  In broad strokes, the plan is:

1. Implement a new, more compact API for defining schema classes (fka model 
classes) and their attributes, in peak.schema.

2. Implement a new, low-impedance O-R mapping for use with said API, in 
peak.query.

3. Begin implementing alternatives to other peak.model features atop the 
peak.schema support, and gradually migrating PEAK's own usage of peak.model.

4. Deprecate use of peak.model and peak.storage.data_managers in favor of 
peak.schema and peak.query.

These steps may take a *long* time, and they're not even started yet.  Even 
when #4 finally occurs (maybe a year from now?), the existing stuff will 
still be distributed and bug-fixed for some time after that.  So, the main 
risk you incur is that I don't plan to add any new features to peak.model 
or data_managers, even before #1 is started.  So, what you see right now is 
what you get, unless you manage to find an actual bug.

Of course, if people come up with patches for improvements, I'll vet them 
and consider them for inclusion; I'm just not planning to come up with any 
of my own.