[TransWarp] PROPOSAL: Rename "TransWarp" itself

[Phillip J. Eby]

At 12:14 PM 6/10/02 +0200, Roché Compaan wrote:

>Ulrich's examples and my experience with ZPatterns helped a lot in my
>understanding.  I have made a new connection class for a MySQLConnection
>and started working on a SQLModel.  I'd love to help with PEAK ;)
>development if I my brain doesn't overload but module inheritance
>simplifies things a lot, suprisingly.  My primary concern is data
>abstraction for SQL and ZODB storage.  How far is development on a
>SQLModel and what should I keep in mind when doing this?

As I've been saying, the TW.Database package is going to get refactored.  I 
don't know exactly how yet, but the level of complexity that's there right 
now bothers me.  The system needs a better way of dealing with alternate DB 
drivers, WarpCORE needs to be integrated, and management of metadata 
regarding the table structures (i.e., allowing creation/modification of 
tables at application install time) needs to be there, too.

I like the metadata capabilities and some of the data capabilities in the 
.NET framework's database object model, so that may be an inspiration.

One of the specific things I know I want to redo is the way connection 
objects return results.  That code was ported from my old app server, ASDF, 
and it doesn't fit the TW model very well.  It also doesn't take advantage 
of iterators, which I think have some potential performance benefits in 
dealing with large queries.

One of the things that ZODB's persistence model has going for it is 
simplicity; I'd like to try to get more of it into TW.Database.  The only 
requirements that I have for the DataModel level stuff that ZODB doesn't 
really implement are multiple ways of identifying the same object, and 
pre-commit writebacks.  If I could find a way to incorporate those concepts 
into the ZODB framework and make RecordManagers be ZODB "database" objects, 
I'd do it in a heartbeat.  The reason being that I could use its caching, 
state management, etc. and not have to reinvent those wheels.

Also, the current TW.Database.DataModel system was designed *pre-2.2*.  It 
doesn't really take advantage of metaclasses, descriptors, etc., except in 
very primitive ways that were tacked on during porting from earlier 
versions of TW.  One reason I went with a mapping interface for records had 
to do with performance issues for __getattr__ that would go away if 
descriptors were used instead.  So it may be that the rewrite will use 
record attributes instead of __getitem__.  Likewise, since class methods 
now exist, it may be that record types will be implemented as classes, with 
queries as class methods, similar to PyDO.  (That might actually be a bit 
difficult, since there's no way in the CIS/SEF architecture for a class to 
know its context, without me making a new Autocreatable metaclass.)

Anyway, as you can see, I don't know where exactly it's going to land.  I 
do know, however, that the parts of TW that are quite solid (module 
inheritance and CIS, primarily) need to get documented and released before 
I try to solidify the higher layers like SEF and Database.  The Naming 
package will also probably join the ranks of the solid and documented 
before I start in on SEF and Database, as Ty and I have some requirements 
in the next month or so that may need the Naming piece more than any other 
current part of TW.  It's quite possible that I'll indeed yank the Naming 
package out of TW and into PEAK before anything else goes into PEAK.

(Assuming, of course, there are no better name suggestions or loud 
objections to the renaming.)