Primary Key - no longer needed?

Primary Key - no longer needed?

sitesurfersitesurfer Posts: 34Questions: 9Answers: 0

Quickie, just updated the libs after a year or so and realised that the editor (php) server side initialisation is no longer the same. Previously I have used a primary key to determine the correct field to edit - however on the new libs - there appears to be nowhere to set this pk - I'm wondering what magic you use to determine the correct field to use when editing a row?

Answers

  • sitesurfersitesurfer Posts: 34Questions: 9Answers: 0

    Should add that I am going from 1.3 to 1.5.2

  • sitesurfersitesurfer Posts: 34Questions: 9Answers: 0
    edited November 2015

    After hunting I found this.

    /**
         * Get / set the primary key.
         *
         * The primary key must be known to Editor so it will know which rows are being
         * edited / deleted upon those actions. The default value is 'id'.
         *  @param string $_ Primary key's name. If not given, then used as a getter.
         *  @return string|self Primary key value if no parameter is given, or
         *    self if used as a setter.
         */
        public function pkey ( $_=null )
        {
            return $this->_getSet( $this->_pkey, $_ );
        }
    
  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin

    Hi,

    The primary key is required - Editor needs to be able to construct the update SQL with information about which row to edit (the primary key is currently the only option for this in the pre-built libraries).

    The client / server data interchange used by Editor changed with the 1.5 release. The upgrade notes detail these changes, and also how to use the old scheme if you need to revert back to it (although you would loose the ability to edit multiple rows at the same time).

    Allan

  • sitesurfersitesurfer Posts: 34Questions: 9Answers: 0

    Hi Allan (and thanks for replying given the new addition (congrats!))

    It would appear that in essence the setup is identical to previously, its the way its transmitted (as per docs you link) which has changed.

    I think whats throwing me is that somehow I cant select the index of the POST array like I used to on a prior to edit/insert/delete action.

    $_POST['data'][0]...blah should work but doesnt. (To get the row id back).

    I'll figure it out :)

  • sitesurfersitesurfer Posts: 34Questions: 9Answers: 0

    Gone back to previous legacy Ajax as per notes.

    Will move forward with new pages/scripts using new code and cut the cloth accordingly.

    Thanks!

  • sitesurfersitesurfer Posts: 34Questions: 9Answers: 0

    aach..

    So I reverted to old style ajax.

    The editor (on a remove) is sending this:

    action: remove
    id[]: row_86

    and I am getting an error from the php editor class:

    <b>Notice</b>: Undefined index: data in <b>/jquery/DataTables
    /Editor-1.5.2/php/Editor/Editor.php</b> on line <b>906</b><br />

    Followed by an error as the data is not an array.

    Odd?

  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin

    I see - unfortunately the libraries that come with 1.5 will operate only with the new style of submitted data. They will not operate with the 1.4 style.

    You could use the 1.4 server-side libraries, but the main benefit of 1.5 was its multi-row editing (which is why this change was required).

    What is it that you want the id for? The server-side events introduced in 1.5 might be a good way to do this for you (depending on what you are doing).

    Allan

This discussion has been closed.