ERP5 is moving toward catalog-storage independance.
Table of Contents
Introduction¶
To do so, business templates must be split when they contain both ZSQLMethods and other kinds of objects.
Here, xyz stands for main package name, and abc stands for catalog storage name.
This graph shows how business templates are supposed to be split.
- - erp5_xyz's ZSQL Methods are moved to a new business template : erp5_xyz_catalog_mysql_innodb. - erp5_xyz_catalog_mysql_innodb must provide a virtual package so alternatives
can exist. - erp5_xyz must depend on a virtual package provided by all alternatives to erp5_xyz_catalog_mysql_innodb.
In the special case of erp5_core, business templates implementing catalog must be named following the erp5_catalog_abc pattern.
Discussion¶
Backward Compatibility¶
jerome: I suggest that we use the historical name erp5_mysql specially, instead of creating failing or creating a new SQLCatalog, catalog method from erp5_mysql will be
installed in the currently active catalog. The main problem is that this is extremly ugly, but this is the price for backward compat. This risk is that we people continue to
erp5_mysql magic name forever, because it would be extremly conviniant.
vincent: I think it can be possible by making a folder whith a tweaked getattr (aq_dynamic ?) which would get objects from the "normal" (erp5_mysql_innodb) catalog while
being able to contain objects from a not-updated business template.
Simple SQL ?¶
jerome: In most case, catalog methods are made of very simple and portable SQL code, so it would be overkill to have to maintain the same
SQL code for all storages, the split is usefull for CREATE TABLE. I don't have a solution for this.
ID must not be an issue¶
jps: when I use ERP5 Catalog in production, I expect the ID of the catalog to be anything because it is very possible that I have created a copy of the default catalog or done
some kind of hot reindexing. In the end, what was installed as "erp5_mysql" can be renamed "erp5_something". At the same time, I feel very uncomfortable to see that upgrades to
business templates end up upgrading "erp5_mysql" rather than "erp5_something". Each time, I have to copy and paste methods from one catalog to the other and check properties on
both sides. In my opinion, the business template system should provide an option to decide which catalog to install / upgrade. And it should, by default, try to upgrade the current
catalog. We could have a popup menu with the following options:
- - Upgrade "erp5_something" - Upgrade "erp5_mysql" - Do nothing
This way, each time we upgrade a business template, we get a chance to upgrade the most appropriate catalog.
vincent: Maybe we even want to be able to install the same method in multiple catalogs. For example, a migration to a new catalog is planned, new catalog is created and a business
template must ge installed before the catalog switch is effective. then the SQL Methods in that business template should go in both the current and the future catalogs.
Maintain a single business template¶
jps: I understand it is sometimes required to specialise methods for each kind of catalog. I also understand that this is a clean approach. But I do not like the idea to maintain
tons of business templates just to define related key expressions. What I would like ideally is the following:
- define generic SQL methods in a single business template as long as it is possible
- split business templates whenever there is really no other way to do
Related Articles¶