Ticket #394 (assigned enhancement)
[patch] Native schema support for PostgreSQL and MSSQL using packages
| Reported by: | impl@… | Owned by: | hans |
|---|---|---|---|
| Priority: | high | Milestone: | To be scheduled |
| Component: | Generator | Version: | devel |
| Severity: | major | Keywords: | |
| Cc: | ulfonk_mennhar@… |
Description
I've created a patch to allow native schema support in databases that allow it. Right now I believe only pgsql and MSSQL do (Oracle sort-of does; see the @note in the patch).
Schemas are defined by a database/table's package, which works exceptionally well with packageObjectModel.
It is, of course, a user option. To enable it, one simply uses propel.packageSchemas in their build.properties.
There's a few small bugfixes in here, too, the most notable of which is fixing ConvertConfTask to understand what to do with multiple data models that share the same database when mapping classes.
This probably needs a lot of testing. I haven't built anything complex using it yet, but if more changes are necessary I'll provide additional patches.
Attachments
-
package_schemas.patch
(20.8 KB) -
added by impl@… 3 years ago.
Change History
comment:1 Changed 3 years ago by hans
- Owner changed from hans to impl
Hi -- sorry it's taken me so long to take a look at this. On the whole, I think this will probably work fine. I agree that it will need some testing; there are probably some unanticipated areas where there could be problems.
The one thing I'd like to avoid, if possible, though is having the model classes look up build properties. I think the only place that was happening was in Table.php (if (DataModelBuilder::getBuildProperty('packageSchemas'))). ... the builder classes can get build properties all they want, but ideally the model classes serve as simple (as simple as possible) representations of the schema from the XML. Hopefully that makes some sense.
comment:2 Changed 3 years ago by hans
- Owner changed from impl to hans
- Priority changed from normal to high
- Status changed from new to assigned
- Severity changed from normal to major
I'm moving this up in priority. I definitely want to get some form of this committed soon -- of course, still true that I'd like to avoid any property lookups in the model.
comment:3 Changed 9 months ago by matthew
- Milestone set to To be scheduled
Assigning 'open' bug to the To be scheduled milestone.
comment:4 Changed 9 months ago by matthew
- Milestone To be scheduled deleted
Doh. Just saw another bug that got moved from 'to be scheduled' to no milestone.