Discussion:
[Erp5-dev] sql_catalog_related_keys
Sebastien Robin
2005-06-02 07:36:37 UTC
Permalink
Hi,

I have found something strange in the implementation of
sql_catalog_related_keys.

There is for example this:
resource_type | movement,catalog/portal_type/z_related_resource

This is great, this will do a join on the table movement. This works well.

Now, I want to do the same thing with another table, for example I want to
do a join with the table stock with the z_related_resource zsql method.
For example:
stock_resource_title | stock,catalog/title/z_related_resource

And you know what ? Then the join will still happen on the movement
table ! Indeed, the ZSQLCatalog assumes that there is only one way to use
z_related_resource. So it will always use the same tables for table_0 and
table_1, whatever we can put on our second sql_catalog_related_keys.

Is it safe to modify the implementation ?

Seb.
--
Sebastien Robin, Nexedi Technical Director
Nexedi: Consulting and Development of Free / Open Source Software
http://www.nexedi.com
ERP5: Free / Open Source ERP Software for small and medium companies
http://www.erp5.org
Storever: OpenBrick, WiFi infrastructure, notebooks and servers
http://www.storever.com
Jean-Paul Smets
2005-06-02 11:17:06 UTC
Permalink
Post by Sebastien Robin
Hi,
I have found something strange in the implementation of
sql_catalog_related_keys.
resource_type | movement,catalog/portal_type/z_related_resource
This is great, this will do a join on the table movement. This works well.
Now, I want to do the same thing with another table, for example I want
to do a join with the table stock with the z_related_resource zsql
stock_resource_title | stock,catalog/title/z_related_resource
And you know what ? Then the join will still happen on the movement
table ! Indeed, the ZSQLCatalog assumes that there is only one way to use
z_related_resource. So it will always use the same tables for table_0 and
table_1, whatever we can put on our second sql_catalog_related_keys.
Is it safe to modify the implementation ?
Well found.

Currently, there is an asumption of single join made per "joining
method" (ex. z_related_resource).

If you plan to modify the implementation, here is what should be done to
improve it:

make sure a single join happens for every combination of
(table list, joining method)

With the idea that if we need both stock_resource_title and
stock_resource_id:
stock_resource_title | stock,catalog/title/z_related_resource
stock_resource_id | stock,catalog/id/z_related_resource

then only one join is made

but if we need:
resource_type | movement,catalog/portal_type/z_related_resource
stock_resource_title | stock,catalog/title/z_related_resource

then two independent joins are made

JPS.
--
Jean-Paul Smets-Solanes, Nexedi CEO - Tel. +33(0)6 62 05 76 14
Nexedi: Consulting and Development of Libre / Open Source Software
http://www.nexedi.com
ERP5: Libre/ Open Source ERP Software for small and medium companies
http://www.erp5.org
Rentalinux: Desktop Linux Server
http://www.rentalinux.com
Loading...