Differences between revisions 15 and 16
Revision 15 as of 2007-01-31 15:20:06
Size: 4086
Comment:
Revision 16 as of 2008-01-03 13:48:09
Size: 4097
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
attachment:BusinessTemplatesDependencies.png
''(source: attachment:BusinessTemplatesDependencies.odg)''
{{attachment:BusinessTemplatesDependencies.png}}
''(source: [[attachment:BusinessTemplatesDependencies.odg]])''
Line 33: Line 33:
jerome: In most case, catalog methods are made of [http://svn.erp5.org/erp5/trunk/bt5/erp5_crm/CatalogMethodTemplateItem/portal_catalog/erp5_mysql/z_related_source_organisation.xml?view=markup&rev=11220  very] [http://svn.erp5.org/erp5/trunk/bt5/erp5_accounting/CatalogMethodTemplateItem/portal_catalog/erp5_mysql/z_delivery_related_mirror_section.xml?view=markup&pathrev=10606 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. jerome: In most case, catalog methods are made of [[http://svn.erp5.org/erp5/trunk/bt5/erp5_crm/CatalogMethodTemplateItem/portal_catalog/erp5_mysql/z_related_source_organisation.xml?view=markup&rev=11220|very]] [[http://svn.erp5.org/erp5/trunk/bt5/erp5_accounting/CatalogMethodTemplateItem/portal_catalog/erp5_mysql/z_delivery_related_mirror_section.xml?view=markup&pathrev=10606|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.

ERP5 is moving toward catalog-storage independance.

To do so, business templates must be split when they contain both ZSQLMethods and other kinds of objects.

BusinessTemplatesDependencies.png (source: BusinessTemplatesDependencies.odg)

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

Discussion/CatalogBusinessTemplates (last edited 2008-01-03 13:48:09 by localhost)