Hello, 2013/9/29 <[email protected]>
> I'm working on an application with plugins, where new plugins created > after the application has been deployed may need to add tables to the > schema. > > Any thoughts on a good way to deal with this? > This is a very interesting problem setup! It is certainly novel to this user group. May I ask in what context you are doing this? Is this for an Open Source framework? Do you control all plugins and their development lifecycles yourself or will there be third-party plugins? > So far I'm thinking about each plugin generate its jooq classes in its own > package for access to its specific tables, while importing the main > application's published jooq classes to access the main application tables. > If a plugin depends on another plugin too it would have to import that > plugin's generated classes. > The difficulty in the above lies in the way you want to handle foreign key meta data. If the actual database schema (main application + plugins mixed) gets strongly coupled, it may be difficult to generate jOOQ classes with all relevant relationships included. If you don't need those meta data, then the above may work. Another option would be to loosely couple the main schema with the plugin schema, e.g. by using views and exposing only those views to the plugins through grants. This would make it hard to define constraints among main schema and plugin schema, which could be an issue for performance and data consistency. > Any thoughts on how to handle the main application's schema changing? For > example if a column type needs to change, or some columns need to be added > or removed. > > So far I'm thinking either to disallow changing column types and removing > columns, allowing only to add new columns and providing migration code, or > to implement a sort of runtime version control on the plugins and maintain > some information about which plugins require which version of the schema so > they can be automatically disabled or the user notified before any sql > errors happen. > Clearly, you will need to implement semantic versioning (http://semver.org) "by convention". Some elements (schemas, tables, columns, constraints) must be left untouched by plugins, others can be enhanced, but I doubt that plugins may remove / replace stuff from other schema elements. In a naive way of thinking, I'd expect each plugin to be put in its own schema with its own database user and grants. Extensions to "higher level" tables would only be possible by implementing 1:1 relationships, such as MAIN_SCHEMA.SOME_TABLE <=> PLUGIN_SCHEMA.SOME_TABLE_EXTENSION Cheers Lukas -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
