Integrity checks, if removed, why?
Because tehy did not actually add much to functionality while making things needlessly complex.
If a db does not support certain features, it is not up to us to provide these. Especially if it may gets upported in a future version.
If we could keep the database structure the same as previous version, people can direct use the new storage on their old database.
The old database system for postgresql is too complex. I suggest that if you want to build this functionality for older system, you make it a sperate download that peopel can install. This would include a seperate resource file (postgresqlXX.xml) and possibly (if needed, but discouraged) a class.
Well, maybe we need to put code in the postgresqlclass, in which things are specified like
if version == 71
else if version == 72
else if version == 73
There is no postgresql class. There is only one staorage class fro OO databases, which uses configuration paarmeters to handle certain details.
Otherwise i need to make 3 classes, to get it working with the database?
You can configure quite a lot with the resource. The aim is to not need specific database code, but provide some options that you can configure if the database needs it. If there are options that need to be adde to facilitate gfeatures of postgresqld, you are welcome to make suggestions.
I'm not against old-postgresql-database-support code, but I woudl like to see it as a separate download or application, rather than integrated in the new storage layer as 'MMBAse core code'.
Changes:
Bytedata:
=============
Old version: was stored inside different types of fields, depeding on the version New version: stored to disk
Fix to get it upwards compatible: Add the code to work with barray
You can turn of storing blobs to disk in the resource.
Table structure: (are we still using extends?)
Yes
Sequences:
Still the same, these are done with schemes. See the postgresql resource for how the SEQUENCE commands are set up.
Primary keys:Unchanged.
Foreignkey checks
Removed the foreign-key-simulating triggers.
Postgresql has no foreign-key scheme.
It may be possible to add the code for triggers (after all, they are SQL commands) in the resource by embedding them in the schemes.
I'm not in favor as we had problems with them while dumping/importing a db. Also, it is a matter of design choice: to not explixitly try to hack a fix for a feature that is not supported by the db. Better to encourage the db-buidlers to fix it.
Btw I still have to create proper documentation on setting up the resource, so I don't blame people for not realizing what is possible with the new layer.
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Never summon anything bigger than your head."
