Primary key element is not available in data set

cr1st1

Hi!

The editor is defined like this :

$editor = Editor::inst( $db, 'table1', array('field1', 'field2') )
    ->fields(
        Field::inst( 'table1.field1', 'field1'),
        Field::inst( 'table1.field2', 'field2')
    )
    ->leftJoin( 'table2', 'table2.field1', '=', 'table1.field1' )
    ->process( $_POST )
    ->data();

When i try to add a record i get this error Primary key element is not available in data set

If i define it like this :

$editor = Editor::inst( $db, 'table1', array('field1', 'field2') )
    ->fields(
        Field::inst( 'table1.field1'),
        Field::inst( 'table1.field2')
    )
    ->leftJoin( 'table2', 'table2.field1', '=', 'table1.field1' )
    ->process( $_POST )
    ->data();

it works.

I would like to use field names not the table.field format
I don't want to use the actual database naming
How can i do this ?

I see that the error is generated in function pkeyToValue that calls function _readProp in witch you search the table name in an array of fields names.

allan

That's a good question - I don't think we've come across that before or tested for it. Are you submitting the fields without the table names when using the second parameter for the Field instance?

Allan

aharro12

I would of thought this would be the setup as you already defined table1 after $db

Field::inst( 'field1', 'field1'),

cr1st1

@allan

i submit the fields without table name. The editor looks like this :

editor = new $.fn.dataTable.Editor({
    "ajax": {"url": "ajax.php"},
    "fields": [
        {"name": "field1","label": "Label1"},
        {"name": "field2","label": "Label2"}
    }],
    table: "#dt"
});

I do this because

if the PHP API is like this (the way i want - with table name hidden)

$editor = Editor::inst( $db, 'table1', array('field1', 'field2') )
    ->fields(
        Field::inst( 'table1.field1', 'field1'),
        Field::inst( 'table1.field2', 'field2')
    )
    ->leftJoin( 'table2', 'table2.field1', '=', 'table1.field1' )
    ->process( $_POST )
    ->data();

and i edit the editor to include the table name

editor = new $.fn.dataTable.Editor({
    "ajax": {"url": "ajax.php"},
    "fields": [
        {"name": "table1.field1","label": "Label1"},
        {"name": "table1.field2","label": "Label2"}
    }],
    table: "#dt"
});

so the editor will submit the table name

action: create
data[0][table1][field1]: 1234
data[0][table1][field2]: abcd

i get this error:

When inserting into a compound key table, all fields that are part of the compound key must be submitted with a specific value.

allan

Thank you. If you are using:

Field::inst( 'table1.field1', 'field1'),

then on the client-side you should just use name: 'field1' since the second parameter for Field::inst() sets the JSON / HTTP variable name.

Allan

cr1st1

Well @allan that's the problem ... i can't use name: 'field1' for fields that are part of the primary key of the table when i have on server side
Field::inst( 'table1.field1', 'field1') because i receive the error
Primary key element is not available in data set

For primary keys i have to use name: 'table1.field1' because of how function _readProp from PHP API handles this situation

For other fields ( not primary keys ) it works - i can use name: 'field3'

allan

Sorry - I didn't quite connect all the dots. I agree - that looks wrong. I've filed a bug report in our internal tracker to have this addressed (if it can be without backwards compatibility issues) for 1.9.1.

Allan

cr1st1

Thank you

allan

I've just been looking into this and I fear that I don't see a good way to handle this in the code. The main issue is that if you are using a join, Editor will automatically prefix the table names to the primary key column names in order to ensure there are no clashes with the joined table(s).

That's okay on read, but a problem on write since pkeyToValue is looking at the array of data the client submitted, rather than one translated from the client submission into the db parameters.

It possibly should do that and I'm keeping this issue open internally, but I'm concerned that its going to take a fair amount of development time to do when there is a reliable workaround - not using the http alias.

Allan