Are there the same checks?
What checks?
Integrity checks, if removed, why?
Is it backwards / forwards compatible?
Forwards compatible? To what? This is the new system.
Just curious ;-)
As to backwards compatible, 1.7 still contains the old support classes, so unless you change your configuration, nothing changes. You needf to turn on the new storage in 1.7
In 1.8, teh old classes will be removed and the new storage system will be default. This emans you ahve one release for switching to the enw storage, either by adapting the database or by creating a new postgresql configuration resource, and igf needed an extension on the storage class.
If we could keep the database structure the same as previous version, people can direct use the new storage on their old database.
The reason why i ask this is, since there are some -silly- transactions
/ commit's needed in certain versions, which in other versions lead to
an error(and yes, this is in the situation of byte thingies).
Which is why we don't store blobs in the database any more. However, all commits are done in transactions now, so this might solve the problem. Then again, I am unsure. I personally do not feel much from adding 3+ postgresql classes to storage if you can circumvent all problems by storing blobs on disk.
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
Otherwise i need to make 3 classes, to get it working with the database?
Bottomline:
I want to see from without the database which changes have been made, if this is known:
- We can see the benefids
- Explain why certain things are solved different
- Explain to people why they should use the storage classes
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 /oid (but not recommended)
Table structure: (are we still using extends?) ============= Old version: ?? New version: ?? Fix to get it upwards compatible: ??
Sequences: ============= Old version: ?? New version: ?? Fix to get it upwards compatible: ??
Primary keys: ============= Old version: ?? New version: ?? Fix to get it upwards compatible: ??
Foreignkey checks ============= Old version: ?? New version: ?? Fix to get it upwards compatible: ??
You said something about an trigger that has been removed. Is this the trigger that checks the foreignkeys? If this has been removed, i will still be upwards complatible.
But, postgresql offers us a way to verify our database, what was the reason not to do this?
As to the storage lookup xml, I noticed postgresql isn't in there. I will add it.
thanx
Storage is totally overhauled. All code is new, and the API of storage '1.6' and storage '1.7' are totally different.
Great! :-)
-- Time is on my side,....
Eduard Witteveen +316 414 789 23
