Ticket #394 (assigned enhancement)

Opened 3 years ago

Last modified 4 months ago

[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:

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 Download (20.8 KB) - added by impl@… 3 years ago.

Change History

Changed 3 years ago by impl@…

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.

Changed 2 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.

Changed 4 months ago by matthew

  • milestone set to To be scheduled

Assigning 'open' bug to the To be scheduled milestone.

Changed 4 months ago by matthew

  • milestone To be scheduled deleted

Doh. Just saw another bug that got moved from 'to be scheduled' to no milestone.

Changed 4 months ago by matthew

  • milestone set to To be scheduled

Per François, tickets should be in 'To be scheduled'.

Note: See TracTickets for help on using tickets.