[Typo3-typo3org] Hosting the TYPO3 sites
wilhelm at icecrash.com
Sun Apr 10 14:30:09 CEST 2005
> Ah, so you'd just recode the needed parts for PostgreSQL. Did you try this?
> Is it that easy?
no not yet. Thats the next part. I've started to migrate the schema to
but thats only a very low priority task. I have other work in front.
But I reviewed the php functions to call. The query funtions has a
swapped argument list, and for the rest of the used mysql function there
> Well, optimizing the schema makes sense for MySQL, too. One *can* have
> referential integrity enforced with MySQL, too. Would you mind sharing with
> me what you did so far?
Sure. I appended a first part of the handmigrated part. With this
reviewed part most of the other schema parts could be migrated by a sed
or perl script. But thats a nice way to do, because you get all the
dirty mysql schema stuff inside postgres.
The appended script is only EXPERIMENTAL level, ok, no deeper tests yet.
But working with one or two guys together, that could become productions
schema very fast.
What needs to be done for REAL migration?
* Define the schema abstract with virtual datatypes and ranges
(I mean Integer 0-255, Boolean, ...)
(Other thoughts about that see
* Think about benefits such as object-relational stuff (be_***, fe_***)
(Important, that could break a migration mysql <-> postgres)
* Real dependencies inside the database (that breaks typo3 totally :)
(I think it's unimpossible to do that ever, because the developers,
also if it's not necessary for mysql, must think about the handling
of other databases, and most will not dot that)
One thing I thought in general is the possibility to do workarounds for
postgres by hiding the real data and catch INSERT,UPDATE and DELETE
query by triggers that do data manipulation. The typo3 known tables (for
select) could be views that let TYPO3 think it has the data as known in
mysql databases. A possible way to do data migration.
More information about the TYPO3-team-typo3org