Lots of people are doing this with 4.0 and Integrator. In fact some of those discussions helping people led directly to this new SPI. That and wanting to allow pluggable schema management tools since we well advertise ours as "not meant for production"
But, all that said, thats not really relevant to whether we externalize rendering or not. Yes, externalizing it could conceivably help some of these (such as yours) custom export/migration tools. On Thu 09 Aug 2012 11:54:23 AM CDT, Eric Dalquist wrote: > > +1 for the externalization. We actually have a custom schema-export tool > for hibernate 4.1 that plugs in with how we configure data sources in > spring much better than the provided tool. > > -Eric > > On 08/09/2012 11:38 AM, Steve Ebersole wrote: >> >> The basics of org.hibernate.service.schema.spi.SchemaManagementTool are >> essentially done. There is a lot of clean up I want to do after >> Configuration is gutted or removed, changing how SchemaExport, etc work >> internally. >> >> But one thing I wanted to discuss was to change up how Exportable works. >> Today, its really not much different than what we used to do. The >> database objects themselves know how to render themselves into SQL >> CREATE/DROP/ALTER commands. What I am contemplating is externalizing >> this rendering (lets call them ExportableRenderer, thought better names >> welcome). This would serve 2 useful purposes: >> 1) Clean up the Table, Sequence, etc code clutter. >> 2) Allow plugging in alternate renderings for things. This could be >> dialects or users or event custom SchemaManagementTool supplied. >> >> WDYT? >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- > st...@hibernate.org > http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
