Webware for Python

Update of /cvsroot/webware/Webware/MiddleKit/Docs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30459

Modified Files:
	RelNotes-X.Y.html 
Log Message:
- edits


Index: RelNotes-X.Y.html
===================================================================
RCS file: /cvsroot/webware/Webware/MiddleKit/Docs/RelNotes-X.Y.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** RelNotes-X.Y.html	28 Feb 2004 01:20:31 -0000	1.5
--- RelNotes-X.Y.html	28 Feb 2004 01:31:45 -0000	1.6
***************
*** 36,40 ****
  <h3>Obj Ref Columns</h3>
  
! <p> A long standing flaw in MiddleKit was the use of 64-bit integer SQL columns to store references/pointers to objects. The first 32-bits were for the class id and the second 32-bits were for the object id. These are difficult to work with from SQL. For example, an object reference to (classId=1, objId=1) showed as 4294967297 in SQL and couldn't not be readily joined with other tables.
  
  <p> The new approach is to break these values into two SQL columns. If the attribute name is "foo" then the SQL columns will be named "fooClassId" and "fooObjId". If, for some reason, you don't like those suffixes, you can customize them through the setting <a href=UsersGuide.html#Configuration_ObjRefSuffixes >ObjRefSuffixes</a>. As always, the class ids are stored in the _MKClassIds table that MiddleKit automatically generates.
--- 36,40 ----
  <h3>Obj Ref Columns</h3>
  
! <p> A long standing flaw in MiddleKit was the use of 64-bit integer SQL columns to store references/pointers to objects. The first 32-bits were for the class id and the second 32-bits were for the object id, information that is necessary because of inheritance and the creation of one SQL table per Python class. These 64-bit columns, packed with two numbers, are difficult to work with from SQL. For example, an object reference to (classId=1, objId=1) showed as 4294967297 in SQL and could not be readily joined with other tables.
  
  <p> The new approach is to break these values into two SQL columns. If the attribute name is "foo" then the SQL columns will be named "fooClassId" and "fooObjId". If, for some reason, you don't like those suffixes, you can customize them through the setting <a href=UsersGuide.html#Configuration_ObjRefSuffixes >ObjRefSuffixes</a>. As always, the class ids are stored in the _MKClassIds table that MiddleKit automatically generates.
***************
*** 45,49 ****
  <h3>SQLGenerator.config</h3>
  
! <p> There used to be another config file, besides Settings.config, named SQLGenerator.config, with a single setting, DropStatements. That file is no longer used and the setting has been moved to Settings.config. If you have a SQLGenerator.config in your model directories, move the setting over.
  
  
--- 45,49 ----
  <h3>SQLGenerator.config</h3>
  
! <p> There used to be another config file, besides Settings.config, named SQLGenerator.config, with a single setting, DropStatements. That file is no longer used and the setting has been moved to Settings.config. If you have SQLGenerator.config in a model directory, move the setting over.
  
  
***************
*** 63,69 ****
  <h2>Improvements and Refinements</h2>
  <ul>
! 	<li>Improved error message when there are errors in the model (instead of
! 		cryptic tracebacks).  In many cases the filename of the model and the
! 	line number are printed, along with the error message.
  </ul>
  
--- 63,68 ----
  <h2>Improvements and Refinements</h2>
  <ul>
! 	<li><b>Generate.py</b> does a better job of detecting errors in the class definitions and sample values than before. You are more likely to see a useful error message than a cryptic traceback. However, in those cases where an exception does occur, you can see that just before the exception, Generate.py prints the last attribute that it was processing before the error. You can then search for that attribute in you model and troubleshoot it.
! 
  </ul>