I'd like fabrik to support multiple primary keys (PK)s

wxwok

New Member
When updating a table with multiple primary keys, fabrik only give the
first primary key in its where clause. The result is that if there are
multiple records which has the first primary key and has other primary
keys, it will fail since duplicated primary keys.
I thought a way to workaroud this problem -- create a new primary key calculated using the multiple Primary keys as the first primary key, then the fabrik will not cause database operations failing.

Here is the example:
Steps to reproduce:
1) create the table like the following
2) create a fabrik list for the table, make the form data editable
3) create a fabrik list menu
4) insert or update the list form and save
5) the fabrik will reports the following error since it only use the
first primary key as the primary key.

delimiter $$
CREATE TABLE Industry_has_Elements (
Industry_id int(11) NOT NULL,
Elements_id int(11) NOT NULL,
Weight float DEFAULT NULL,
DefaultValue float DEFAULT NULL,
Description text,
PRIMARY KEY (Industry_id,Elements_id),
KEY fk_Industry_has_Elements_Elements1 (Elements_id),
KEY fk_Industry_has_Elements_Industry1 (Industry_id),
CONSTRAINT fk_Industry_has_Elements_Elements1 FOREIGN KEY (Elements_id)
REFERENCES Elements (id) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT fk_Industry_has_Elements_Industry1 FOREIGN KEY (Industry_id)
REFERENCES Industry (id) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=latin1$$

When updating a record from the form, Fabrik reports:
Error
Duplicate entry '2-1' for key 'PRIMARY' SQL=UPDATE Industry_has_Elements
SET Elements_id='1',Weight='1',DefaultValue='1',Description='sdf' WHERE
Industry_id='2'
 
Fabrik only supports one primary key and MyISAM tables.

Fabrik does provide, using plugins, various ways of updating other tables. Maybe explain what you want to achieve so we can provide alternative solutions.
 
Can you provide more guide of how to write plugins? I'd like to change the SQL before submitting it. I have know I can write php plugin before submitting form data, but how to modify SQL in fabrik way? Do I need to learn it from the source code?
 
Fabrik only supports one primary key and MyISAM tables.[...]
Oh geez - you learn something new every day.
As we are on the verge of enabling e-commerce features, I just changed all my tables to use InnoDB.

Why do you say you only support MyISAM? How 'definite' is that?
What problems can I expect?

InnoDB has become the default storage engine for MySQL - and I thought you guys were always anxious to provide support for the latest and greatest? Besides, MyISAM is antiquated and sucks as storage engine - not to mention InnoDB fully supports transactions needed to enable the development of e-commerce and other robust, business-critical applications.

Please don't tell me after almost 2 years of developing this project that I cannot use InnoDB on fabrik tables - please.
 
I have a site running with InnoDB tables.
I think you can use it as long as you don't have constraints, triggers etc. (or as long as you set up a workflow like e.g canDeleteRow=0 if there's related data).
 
There's a sigh of relief, thanks. :cool:
I still need to do my homework on all the commerce stuff anyhow, as I've never had the need to use it before.
 
InnoDB tables are only problematic if you use foreign key constraints, or cascading triggers, or other features which conflict with the way Fabrik handles joined data. We will actually create InnoDB tables, if that is your database default engine, for repeat data tables.

But we only "support" MyIsam, in the sense that we don't support any of the features of InnoDb tables that actually differentiate them from MyIsam in any real functional sense. So it's a lot easier just to say "we don't support InnoDb", and queitly allow basic use of InnDb without any bells and whistles, than go in to a lengthy explanation of which features we do and don't support.

In Fabrik 4.0 we will probably fully support InnoDb and composite keys. But in 3.x ... nope. It would require entirely rewriting the core join handling, which ain't going to happen.

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top