PK of 0 is not showing in generated URL

[swimlappy]

Hello,

I've got eztables listing model data for several models and it works great. I just noticed something strange today and was wondering if this is a bug or screwy code on my part. My models were already populated with data when I setup eztables. Any record with a pk of 0 is not displaying a valid URL, but instead just shows <pk>. For records with PK of 1 and above the URL is correct.

Any ideas why that might be happening? I used Firebug to check my DOM and aaData actually has the proper PK of 0 returned. Normally my ID field is hidden in my HTML, but I set it to visible and the proper PK is there. It seems that my fnRender call is just not building the URL properly for a PK of 0.

I'm posting my js code that is being called, perhaps I have done something wrong since I am still new to eztables and datatables.

(function($, Django){
    "use strict";
    $(function(){
        $('#dept-table').dataTable({
            "bPaginate": true,
            "sPaginationType": "bootstrap",
            "bProcessing": true,
            "bDeferRender": true,
            "bServerSide": true,
            "bAutoWidth" : false,
            "sServerMethod": "POST", // pretty urls
            "sDom": "<'row-fluid'<'span6'l><'span6'f>r>t<'row-fluid'<'span12'i><'span12 center'p>>",
            "oLanguage": {
                "sLengthMenu": "_MENU_ records per page"
            },
            "sAjaxSource": Django.url('Dept_table_query'),
            "aaSorting": [[ 1, "asc" ]], // Sort by this column descending
            "aoColumns": [
                {
                    "bSortable": false,   // id column is not sortable
                    "bSearchable": false, // id column is not searcheable
                    "bVisible": true,    // id column is hidden normally
                    "aTargets": [0],
                },
                { "sWidth": "15%" }, // 1st column width 
                { "sWidth": "63%" }, // 2nd column width 
                { 
                    "mData": null,
                    "sWidth": "22%",
                    "bSortable": false,   // column is not sortable
                    "bSearchable": false, // column is not searcheable
                    "fnRender": function (oObj) {
                        return ' <a href="' + Django.url('dept_detail', oObj.aData[0]) + '"><i ></i> View</a>'
                             + ' <a href="' + Django.url('dept_update', oObj.aData[0]) + '"><i ></i> Edit</a>'
                             + ' <a href="' + Django.url('dept_delete', oObj.aData[0]) + '"><i ></i> Delete</a>'
                    }
                }  // last, action column
            ],
        });
    });

}(window.jQuery, window.Django));

Thanks for any help

-Jay

[swimlappy]

I read that fnRender is being deprecated in Datatables. So I updated my js code to use mRender and not fnRender. Still get the same results, really weird. Here is the relevant part that was updated. This still fails to render a URL properly if the PK is 0. How strange!

                { 
                    "mData": 0,
                    "sWidth": "22%",
                    "bSortable": false,   // column is not sortable
                    "bSearchable": false, // column is not searcheable
                    "mRender": function (data, type, row) {
                        return ' <a href="' + Django.url('dept_detail', data) + '"><i ></i> View</a>'
                             + ' <a href="' + Django.url('dept_update', data) + '"><i ></i> Edit</a>'
                             + ' <a href="' + Django.url('dept_delete', data) + '"><i ></i> Delete</a>'
                    }

I also had a thought that perhaps there was an issue with a loop, and that the first row rendered was the problem. So I removed 2 records from 2 different models that had a PK of 0. The tables render just fine. So there is definitely something odd going on when PK is 0.

-Jay

[swimlappy]

So Django starts pk at 1 by default, but allows a custom pk index starting at 0, if you desire. I rebuilt my models and data with a pk starting at 1 and don't have any issues. I'm not sure if this should be looked at or not. Someone else might have custom primary keys as well.

Thanks
-Jay

[noirbizarre]

You're right: I assumed IDs starting at 1.
But you're right too: Django allows custom pk starting at 0.
I will fix this issue, but if it's not an issue for you, you can use standard Django PKs while I fix this.

Thanks for the report.

[noirbizarre]

Fixed in 96bcdeab23a3ab6798dbcc0efc09af4724c1f412