Getting values from Datable after a sort?

Community Support
1

After looking through all the Bokeh references I can find I haven’t found an answer to this so I thought I’d post here.

I’m trying to find a way to query the values on selected rows of a DataTable after it has been sorted by clicking on one of the column headers.

Before the table row order gets modified by the sort operation I could use the selected indexes available in a CustomJS callback to get the values contained in the selected rows from the ColumnDataSource used as input to the table. However, when the table rows are reordered with a sort those selection indexes relate to the new order of the rows that are displayed. (i.e. the order oder of the source stays the same but the display order is different.) The reported selection indexes correctly match the display order (e.g. if the third row is selected a selection index of 2 will be reported). However, I can’t figure out how to get the values that are displayed on that row since it now isn’t the third row of the input data source.

I’m sure this must be more simple than I’m trying to make it, any suggestions would be greatly appreciated.

2

I think this may not be possible at the moment, can you open an issue on GitHub? I can think of a few possible approaches offhand, but it will require a little investigation.

Looking at the current code:

  https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86

It *looks* like it actually is trying to update the data source order. I'm not sure how I feel about that. I think maybe I hope that doesn't work, I think a better approach would be to maintain an explicit sorter to use to map to the original data.

Bryan

···

On Jan 6, 2016, at 9:37 PM, Jim Sharpe <[email protected]> wrote:

After looking through all the Bokeh references I can find I haven't found an answer to this so I thought I'd post here.

I'm trying to find a way to query the values on selected rows of a DataTable after it has been sorted by clicking on one of the column headers.

Before the table row order gets modified by the sort operation I could use the selected indexes available in a CustomJS callback to get the values contained in the selected rows from the ColumnDataSource used as input to the table. However, when the table rows are reordered with a sort those selection indexes relate to the new order of the rows that are displayed. (i.e. the order oder of the source stays the same but the display order is different.) The reported selection indexes correctly match the display order (e.g. if the third row is selected a selection index of 2 will be reported). However, I can't figure out how to get the values that are displayed on that row since it now isn't the third row of the input data source.

I'm sure this must be more simple than I'm trying to make it, any suggestions would be greatly appreciated.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

3

I’ve opened issue #3564 and am inclined to agree that actually modifying the order of the source might not be a great idea (who knows what external code might not be expecting that to happen). However it would be great to have some kind of mapping capability so we could somehow get at the values in the selected rows.

I think this may not be possible at the moment, can you open an issue on GitHub? I can think of a few possible approaches offhand, but it will require a little investigation.

Looking at the current code:

    [https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86](https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86)

It looks like it actually is trying to update the data source order. I’m not sure how I feel about that. I think maybe I hope that doesn’t work, I think a better approach would be to maintain an explicit sorter to use to map to the original data.

Bryan

After a bit more testing with v11 RC2 it appears that if the source is indeed getting reordered that the modified version is not getting exposed to with the javascript callback or python code running in a jupyter notebook as the order of the data sources in both those places remains unchanged. (WHich unfortunately means the indexes reported for the selected rows don’t align with the correct data.

···

On Wednesday, January 6, 2016 at 8:48:35 PM UTC-7, Bryan Van de ven wrote:

On Jan 6, 2016, at 9:37 PM, Jim Sharpe [email protected] wrote:

After looking through all the Bokeh references I can find I haven’t found an answer to this so I thought I’d post here.

I’m trying to find a way to query the values on selected rows of a DataTable after it has been sorted by clicking on one of the column headers.

Before the table row order gets modified by the sort operation I could use the selected indexes available in a CustomJS callback to get the values contained in the selected rows from the ColumnDataSource used as input to the table. However, when the table rows are reordered with a sort those selection indexes relate to the new order of the rows that are displayed. (i.e. the order oder of the source stays the same but the display order is different.) The reported selection indexes correctly match the display order (e.g. if the third row is selected a selection index of 2 will be reported). However, I can’t figure out how to get the values that are displayed on that row since it now isn’t the third row of the input data source.

I’m sure this must be more simple than I’m trying to make it, any suggestions would be greatly appreciated.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

4

Hi Byran,

After seeing such rapid progress on other issues such as the push_notebook/comms fix in the latest dev build I’m hopeful that there might have been some movement on this table/sort/selection mapping problem. It’s the last outstanding issue we have before an important client demo. Do you have any further thoughts on what we might be able to do to work around it?

···

On Wednesday, January 6, 2016 at 9:49:35 PM UTC-7, Jim Sharpe wrote:

I’ve opened issue #3564 and am inclined to agree that actually modifying the order of the source might not be a great idea (who knows what external code might not be expecting that to happen). However it would be great to have some kind of mapping capability so we could somehow get at the values in the selected rows.

On Wednesday, January 6, 2016 at 8:48:35 PM UTC-7, Bryan Van de ven wrote:

I think this may not be possible at the moment, can you open an issue on GitHub? I can think of a few possible approaches offhand, but it will require a little investigation.

Looking at the current code:

    [https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86](https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86)

It looks like it actually is trying to update the data source order. I’m not sure how I feel about that. I think maybe I hope that doesn’t work, I think a better approach would be to maintain an explicit sorter to use to map to the original data.

Bryan

After a bit more testing with v11 RC2 it appears that if the source is indeed getting reordered that the modified version is not getting exposed to with the javascript callback or python code running in a jupyter notebook as the order of the data sources in both those places remains unchanged. (WHich unfortunately means the indexes reported for the selected rows don’t align with the correct data.

On Jan 6, 2016, at 9:37 PM, Jim Sharpe [email protected] wrote:

After looking through all the Bokeh references I can find I haven’t found an answer to this so I thought I’d post here.

I’m trying to find a way to query the values on selected rows of a DataTable after it has been sorted by clicking on one of the column headers.

Before the table row order gets modified by the sort operation I could use the selected indexes available in a CustomJS callback to get the values contained in the selected rows from the ColumnDataSource used as input to the table. However, when the table rows are reordered with a sort those selection indexes relate to the new order of the rows that are displayed. (i.e. the order oder of the source stays the same but the display order is different.) The reported selection indexes correctly match the display order (e.g. if the third row is selected a selection index of 2 will be reported). However, I can’t figure out how to get the values that are displayed on that row since it now isn’t the third row of the input data source.

I’m sure this must be more simple than I’m trying to make it, any suggestions would be greatly appreciated.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

5

Hi Jim,

Not sure if I've missed an email, but just to let you know that I'm not
aware of any movement in the DataTable widget.

However, the User Defined Models framework is now pretty robust and I'm
wondering whether you can use that to do the integration of whatever JS
Data Table plus Bokeh. If you're in the notebook, I hear good things
about qgrid (although I've never used it myself).

Sincerely,

Sarah Bird

···

On 1/26/16 7:02 AM, Jim Sharpe wrote:

Hi Byran,

After seeing such rapid progress on other issues such as the
push_notebook/comms fix in the latest dev build I'm hopeful that there
might have been some movement on this table/sort/selection mapping
problem. It's the last outstanding issue we have before an important
client demo. Do you have any further thoughts on what we might be able
to do to work around it?

On Wednesday, January 6, 2016 at 9:49:35 PM UTC-7, Jim Sharpe wrote:

    I've opened issue #3564
    <Issues · bokeh/bokeh · GitHub; and am inclined to
    agree that actually modifying the order of the source might not be a
    great idea (who knows what external code might not be expecting that
    to happen). However it would be great to have some kind of mapping
    capability so we could somehow get at the values in the selected rows.

    On Wednesday, January 6, 2016 at 8:48:35 PM UTC-7, Bryan Van de ven > wrote:

        I think this may not be possible at the moment, can you open an
        issue on GitHub? I can think of a few possible approaches
        offhand, but it will require a little investigation.

        Looking at the current code:

                https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86
        <https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86&gt;

        It *looks* like it actually is trying to update the data source
        order. I'm not sure how I feel about that. I think maybe I hope
        that doesn't work, I think a better approach would be to
        maintain an explicit sorter to use to map to the original data.

        Bryan

    After a bit more testing with v11 RC2 it appears that if the source
    is indeed getting reordered that the modified version is not getting
    exposed to with the javascript callback or python code running in a
    jupyter notebook as the order of the data sources in both those
    places remains unchanged. (WHich unfortunately means the indexes
    reported for the selected rows don't align with the correct data.

        > On Jan 6, 2016, at 9:37 PM, Jim Sharpe <[email protected]> wrote:
        >
        > After looking through all the Bokeh references I can find I
        haven't found an answer to this so I thought I'd post here.
        >
        > I'm trying to find a way to query the values on selected rows
        of a DataTable after it has been sorted by clicking on one of
        the column headers.
        >
        > Before the table row order gets modified by the sort operation
        I could use the selected indexes available in a CustomJS
        callback to get the values contained in the selected rows from
        the ColumnDataSource used as input to the table. However, when
        the table rows are reordered with a sort those selection indexes
        relate to the new order of the rows that are displayed. (i.e.
        the order oder of the source stays the same but the display
        order is different.) The reported selection indexes correctly
        match the display order (e.g. if the third row is selected a
        selection index of 2 will be reported). However, I can't figure
        out how to get the values that are displayed on that row since
        it now isn't the third row of the input data source.
        >
        > I'm sure this must be more simple than I'm trying to make it,
        any suggestions would be greatly appreciated.
        >
        > --
        > You received this message because you are subscribed to the
        Google Groups "Bokeh Discussion - Public" group.
        > To unsubscribe from this group and stop receiving emails from
        it, send an email to bokeh+un...@continuum.io.
        > To post to this group, send email to bo...@continuum.io.
        > To view this discussion on the web visit
        https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io
        <https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io&gt;\.

        > For more options, visit
        https://groups.google.com/a/continuum.io/d/optout
        <https://groups.google.com/a/continuum.io/d/optout&gt;\.

--
You received this message because you are subscribed to the Google
Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225d561-9f70-4c88-a776-4178adb510cf%40continuum.io
<https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225d561-9f70-4c88-a776-4178adb510cf%40continuum.io?utm_medium=email&utm_source=footer&gt;\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

6

Hi Sarah,

Thanks much for following up. I just looked again for documentation on how to implement user-defined models in Bokeh but didn’t come up with anything. Would it be possible for you to point me to where I could find it?

In the meantime the recommendation for qgrid was quite helpful. I just took a quick look and it does appear to be very notebook friendly and might just do the trick. :slight_smile:

···

On Thu, Jan 28, 2016 at 4:46 PM, Sarah Bird [email protected] wrote:

Hi Jim,

Not sure if I’ve missed an email, but just to let you know that I’m not

aware of any movement in the DataTable widget.

However, the User Defined Models framework is now pretty robust and I’m

wondering whether you can use that to do the integration of whatever JS

Data Table plus Bokeh. If you’re in the notebook, I hear good things

about qgrid (although I’ve never used it myself).

Sincerely,

Sarah Bird

On 1/26/16 7:02 AM, Jim Sharpe wrote:

Hi Byran,

After seeing such rapid progress on other issues such as the

push_notebook/comms fix in the latest dev build I’m hopeful that there

might have been some movement on this table/sort/selection mapping

problem. It’s the last outstanding issue we have before an important

client demo. Do you have any further thoughts on what we might be able

to do to work around it?

On Wednesday, January 6, 2016 at 9:49:35 PM UTC-7, Jim Sharpe wrote:

I've opened issue #3564

<[https://github.com/bokeh/bokeh/issues/3564](https://github.com/bokeh/bokeh/issues/3564)> and am inclined to

agree that actually modifying the order of the source might not be a

great idea (who knows what external code might not be expecting that

to happen).  However it would be great to have some kind of mapping

capability so we could somehow get at the values in the selected rows.

On Wednesday, January 6, 2016 at 8:48:35 PM UTC-7, Bryan Van de ven

wrote:

    I think this may not be possible at the moment, can you open an

    issue on GitHub? I can think of a few possible approaches

    offhand, but it will require a little investigation.

    Looking at the current code:

            [https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86](https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86)

    <[https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86](https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86)>

    It *looks* like it actually is trying to update the data source

    order. I'm not sure how I feel about that. I think maybe I hope

    that doesn't work, I think a better approach would be to

    maintain an explicit sorter to use to map to the original data.

    Bryan

After a bit more testing with v11 RC2 it appears that if the source

is indeed getting reordered that the modified version is not getting

exposed to with the javascript callback or python code running in a

jupyter notebook as the order of the data sources in both those

places remains unchanged. (WHich unfortunately means the indexes

reported for the selected rows don't align with the correct data.

    > On Jan 6, 2016, at 9:37 PM, Jim Sharpe <[email protected]> wrote:

    >

    > After looking through all the Bokeh references I can find I

    haven't found an answer to this so I thought I'd post here.

    >

    > I'm trying to find a way to query the values on selected rows

    of a DataTable after it has been sorted by clicking on one of

    the column headers.

    >

    > Before the table row order gets modified by the sort operation

    I could use the selected indexes available in a CustomJS

    callback to get the values contained in the selected rows from

    the ColumnDataSource used as input to the table.  However, when

    the table rows are reordered with a sort those selection indexes

    relate to the new order of the rows that are displayed. (i.e.

    the order oder of the source stays the same but the display

    order is different.) The reported selection indexes correctly

    match the display order (e.g. if the third row is selected a

    selection index of 2 will be reported).  However, I can't figure

    out how to get the values that are displayed on that row since

    it now isn't the third row of the input data source.

    >

    > I'm sure this must be more simple than I'm trying to make it,

    any suggestions would be greatly appreciated.

    >

    > --

    > You received this message because you are subscribed to the

    Google Groups "Bokeh Discussion - Public" group.

    > To unsubscribe from this group and stop receiving emails from

    it, send an email to [email protected].

    > To post to this group, send email to [email protected].

    > To view this discussion on the web visit

    [https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io](https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io)

    <[https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io](https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io)>.

    > For more options, visit

    [https://groups.google.com/a/continuum.io/d/optout](https://groups.google.com/a/continuum.io/d/optout)

    <[https://groups.google.com/a/continuum.io/d/optout](https://groups.google.com/a/continuum.io/d/optout)>.

–

You received this message because you are subscribed to the Google

Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to [email protected]

mailto:[email protected].

To post to this group, send email to [email protected]

mailto:[email protected].

To view this discussion on the web visit

https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225d561-9f70-4c88-a776-4178adb510cf%40continuum.io

<https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225d561-9f70-4c88-a776-4178adb510cf%40continuum.io?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

You received this message because you are subscribed to a topic in the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this topic, visit https://groups.google.com/a/continuum.io/d/topic/bokeh/5HQ8gPssZB4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/56AAA838.502%40gmail.com.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

Jim Sharpe
[email protected] www.sharpe.com (970) 209-3810

7

Hi Sarah,

Unfortunately it appears that qgrid behaves the same way that the Bokeh table does. Specifically, the indices that are returned from get_selected_rows() don’t match the rows in the dataframe after the order of the rows in altered with a sort and there doesn’t appear any way to map the them back to the row in the dataframe or even just get their contents.

···

On Thu, Jan 28, 2016 at 4:46 PM, Sarah Bird [email protected] wrote:

Hi Jim,

Not sure if I’ve missed an email, but just to let you know that I’m not

aware of any movement in the DataTable widget.

However, the User Defined Models framework is now pretty robust and I’m

wondering whether you can use that to do the integration of whatever JS

Data Table plus Bokeh. If you’re in the notebook, I hear good things

about qgrid (although I’ve never used it myself).

Sincerely,

Sarah Bird

On 1/26/16 7:02 AM, Jim Sharpe wrote:

Hi Byran,

After seeing such rapid progress on other issues such as the

push_notebook/comms fix in the latest dev build I’m hopeful that there

might have been some movement on this table/sort/selection mapping

problem. It’s the last outstanding issue we have before an important

client demo. Do you have any further thoughts on what we might be able

to do to work around it?

On Wednesday, January 6, 2016 at 9:49:35 PM UTC-7, Jim Sharpe wrote:

I've opened issue #3564

<[https://github.com/bokeh/bokeh/issues/3564](https://github.com/bokeh/bokeh/issues/3564)> and am inclined to

agree that actually modifying the order of the source might not be a

great idea (who knows what external code might not be expecting that

to happen).  However it would be great to have some kind of mapping

capability so we could somehow get at the values in the selected rows.

On Wednesday, January 6, 2016 at 8:48:35 PM UTC-7, Bryan Van de ven

wrote:

    I think this may not be possible at the moment, can you open an

    issue on GitHub? I can think of a few possible approaches

    offhand, but it will require a little investigation.

    Looking at the current code:

            [https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86](https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86)

    <[https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86](https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86)>

    It *looks* like it actually is trying to update the data source

    order. I'm not sure how I feel about that. I think maybe I hope

    that doesn't work, I think a better approach would be to

    maintain an explicit sorter to use to map to the original data.

    Bryan

After a bit more testing with v11 RC2 it appears that if the source

is indeed getting reordered that the modified version is not getting

exposed to with the javascript callback or python code running in a

jupyter notebook as the order of the data sources in both those

places remains unchanged. (WHich unfortunately means the indexes

reported for the selected rows don't align with the correct data.

    > On Jan 6, 2016, at 9:37 PM, Jim Sharpe <[email protected]> wrote:

    >

    > After looking through all the Bokeh references I can find I

    haven't found an answer to this so I thought I'd post here.

    >

    > I'm trying to find a way to query the values on selected rows

    of a DataTable after it has been sorted by clicking on one of

    the column headers.

    >

    > Before the table row order gets modified by the sort operation

    I could use the selected indexes available in a CustomJS

    callback to get the values contained in the selected rows from

    the ColumnDataSource used as input to the table.  However, when

    the table rows are reordered with a sort those selection indexes

    relate to the new order of the rows that are displayed. (i.e.

    the order oder of the source stays the same but the display

    order is different.) The reported selection indexes correctly

    match the display order (e.g. if the third row is selected a

    selection index of 2 will be reported).  However, I can't figure

    out how to get the values that are displayed on that row since

    it now isn't the third row of the input data source.

    >

    > I'm sure this must be more simple than I'm trying to make it,

    any suggestions would be greatly appreciated.

    >

    > --

    > You received this message because you are subscribed to the

    Google Groups "Bokeh Discussion - Public" group.

    > To unsubscribe from this group and stop receiving emails from

    it, send an email to [email protected].

    > To post to this group, send email to [email protected].

    > To view this discussion on the web visit

    [https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io](https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io)

    <[https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io](https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io)>.

    > For more options, visit

    [https://groups.google.com/a/continuum.io/d/optout](https://groups.google.com/a/continuum.io/d/optout)

    <[https://groups.google.com/a/continuum.io/d/optout](https://groups.google.com/a/continuum.io/d/optout)>.

–

You received this message because you are subscribed to the Google

Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to [email protected]

mailto:[email protected].

To post to this group, send email to [email protected]

mailto:[email protected].

To view this discussion on the web visit

https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225d561-9f70-4c88-a776-4178adb510cf%40continuum.io

<https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225d561-9f70-4c88-a776-4178adb510cf%40continuum.io?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

You received this message because you are subscribed to a topic in the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this topic, visit https://groups.google.com/a/continuum.io/d/topic/bokeh/5HQ8gPssZB4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/56AAA838.502%40gmail.com.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

Jim Sharpe
[email protected] www.sharpe.com (970) 209-3810

8

Yeah, I actually don't see anything either.

Maybe Bryan knows where it is.

Here's an example showing it off:
https://github.com/bokeh/bokeh/blob/master/examples/plotting/file/custom_datetime_axis.py

···

On 1/28/16 4:09 PM, Jim Sharpe wrote:

Hi Sarah,

Thanks much for following up. I just looked again for documentation on
how to implement user-defined models in Bokeh but didn't come up with
anything. Would it be possible for you to point me to where I could
find it?

In the meantime the recommendation for qgrid was quite helpful. I just
took a quick look and it does appear to be very notebook friendly and
might just do the trick. :slight_smile:

--
Jim Sharpe
[email protected] <mailto:[email protected]> www.sharpe.com
<http://www.sharpe.com> (970) 209-3810

On Thu, Jan 28, 2016 at 4:46 PM, Sarah Bird <[email protected] > <mailto:[email protected]>> wrote:

    Hi Jim,

    Not sure if I've missed an email, but just to let you know that I'm not
    aware of any movement in the DataTable widget.

    However, the User Defined Models framework is now pretty robust and I'm
    wondering whether you can use that to do the integration of whatever JS
    Data Table plus Bokeh. If you're in the notebook, I hear good things
    about qgrid (although I've never used it myself).

    Sincerely,

    Sarah Bird

    On 1/26/16 7:02 AM, Jim Sharpe wrote:
    > Hi Byran,
    >
    > After seeing such rapid progress on other issues such as the
    > push_notebook/comms fix in the latest dev build I'm hopeful that there
    > might have been some movement on this table/sort/selection mapping
    > problem. It's the last outstanding issue we have before an important
    > client demo. Do you have any further thoughts on what we might be
    able
    > to do to work around it?
    >
    >
    > On Wednesday, January 6, 2016 at 9:49:35 PM UTC-7, Jim Sharpe wrote:
    >
    > I've opened issue #3564
    > <Issues · bokeh/bokeh · GitHub; and am inclined to
    > agree that actually modifying the order of the source might
    not be a
    > great idea (who knows what external code might not be
    expecting that
    > to happen). However it would be great to have some kind of
    mapping
    > capability so we could somehow get at the values in the
    selected rows.
    >
    > On Wednesday, January 6, 2016 at 8:48:35 PM UTC-7, Bryan Van > de ven > > wrote:
    >
    > I think this may not be possible at the moment, can you
    open an
    > issue on GitHub? I can think of a few possible approaches
    > offhand, but it will require a little investigation.
    >
    > Looking at the current code:
    >
    >
     https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86
    >
     <https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/widget/data_table.coffee#L52-L86&gt;
    >
    >
    > It *looks* like it actually is trying to update the data
    source
    > order. I'm not sure how I feel about that. I think maybe I
    hope
    > that doesn't work, I think a better approach would be to
    > maintain an explicit sorter to use to map to the original
    data.
    >
    > Bryan
    >
    >
    > After a bit more testing with v11 RC2 it appears that if the
    source
    > is indeed getting reordered that the modified version is not
    getting
    > exposed to with the javascript callback or python code running
    in a
    > jupyter notebook as the order of the data sources in both those
    > places remains unchanged. (WHich unfortunately means the indexes
    > reported for the selected rows don't align with the correct data.
    >
    >
    >
    > > On Jan 6, 2016, at 9:37 PM, Jim Sharpe <j...@sharpe.com > <mailto:[email protected]>> wrote:
    > >
    > > After looking through all the Bokeh references I can find I
    > haven't found an answer to this so I thought I'd post here.
    > >
    > > I'm trying to find a way to query the values on selected
    rows
    > of a DataTable after it has been sorted by clicking on one of
    > the column headers.
    > >
    > > Before the table row order gets modified by the sort
    operation
    > I could use the selected indexes available in a CustomJS
    > callback to get the values contained in the selected rows from
    > the ColumnDataSource used as input to the table. However,
    when
    > the table rows are reordered with a sort those selection
    indexes
    > relate to the new order of the rows that are displayed. (i.e.
    > the order oder of the source stays the same but the display
    > order is different.) The reported selection indexes correctly
    > match the display order (e.g. if the third row is selected a
    > selection index of 2 will be reported). However, I can't
    figure
    > out how to get the values that are displayed on that row since
    > it now isn't the third row of the input data source.
    > >
    > > I'm sure this must be more simple than I'm trying to
    make it,
    > any suggestions would be greatly appreciated.
    > >
    > > --
    > > You received this message because you are subscribed to the
    > Google Groups "Bokeh Discussion - Public" group.
    > > To unsubscribe from this group and stop receiving emails
    from
    > it, send an email to bokeh+un...@continuum.io
    <mailto:bokeh%[email protected]>.
    > > To post to this group, send email to bo...@continuum.io
    <mailto:[email protected]>.
    > > To view this discussion on the web visit
    >
     https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io
    >
     <https://groups.google.com/a/continuum.io/d/msgid/bokeh/c649e2f3-8c4c-4b24-bcb4-2efefe4d44c7%40continuum.io&gt;\.
    >
    > > For more options, visit
    > https://groups.google.com/a/continuum.io/d/optout
    > <https://groups.google.com/a/continuum.io/d/optout&gt;\.
    >
    > --
    > You received this message because you are subscribed to the Google
    > Groups "Bokeh Discussion - Public" group.
    > To unsubscribe from this group and stop receiving emails from it, send
    > an email to [email protected] <mailto:bokeh%[email protected]>
    > <mailto:[email protected]
    <mailto:bokeh%[email protected]>>.
    > To post to this group, send email to [email protected] <mailto:[email protected]>
    > <mailto:[email protected] <mailto:[email protected]>>.
    > To view this discussion on the web visit
    > https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225d561-9f70-4c88-a776-4178adb510cf%40continuum.io
    > <https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225d561-9f70-4c88-a776-4178adb510cf%40continuum.io?utm_medium=email&utm_source=footer&gt;\.
    > For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

    --
    You received this message because you are subscribed to a topic in
    the Google Groups "Bokeh Discussion - Public" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/a/continuum.io/d/topic/bokeh/5HQ8gPssZB4/unsubscribe\.
    To unsubscribe from this group and all its topics, send an email to
    [email protected]
    <mailto:bokeh%[email protected]>.
    To post to this group, send email to [email protected]
    <mailto:[email protected]>.
    To view this discussion on the web visit
    https://groups.google.com/a/continuum.io/d/msgid/bokeh/56AAA838.502%40gmail.com\.
    For more options, visit
    https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google
Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAOnSNq9pXBrd2qYNKcuub-iofbMNqqnY5_gAMhQH37OE9Bheyw%40mail.gmail.com
<https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAOnSNq9pXBrd2qYNKcuub-iofbMNqqnY5_gAMhQH37OE9Bheyw%40mail.gmail.com?utm_medium=email&utm_source=footer&gt;\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

9

Hi Jim -

I ran into the same problem today - where I was inserting into/updating a data table based on user interactions on a plot. The table data source ends up getting out of sync w/ the plot and plot data source. I’ll dig into this tomorrow and respond to your GH issue.

···

On Wednesday, January 6, 2016 at 9:37:43 PM UTC-6, Jim Sharpe wrote:

After looking through all the Bokeh references I can find I haven’t found an answer to this so I thought I’d post here.

I’m trying to find a way to query the values on selected rows of a DataTable after it has been sorted by clicking on one of the column headers.

Before the table row order gets modified by the sort operation I could use the selected indexes available in a CustomJS callback to get the values contained in the selected rows from the ColumnDataSource used as input to the table. However, when the table rows are reordered with a sort those selection indexes relate to the new order of the rows that are displayed. (i.e. the order oder of the source stays the same but the display order is different.) The reported selection indexes correctly match the display order (e.g. if the third row is selected a selection index of 2 will be reported). However, I can’t figure out how to get the values that are displayed on that row since it now isn’t the third row of the input data source.

I’m sure this must be more simple than I’m trying to make it, any suggestions would be greatly appreciated.

10

I am having what I think is the exact issue discussed in this thread,
that is, I want to know what row a user selected in a table

but after interactive sorting the table and the returned indices are out of synch

Is there a fix or work around for this?

Is there any way to know the last header column used for sorting?

thanks,

  • john
···

On Thursday, February 18, 2016 at 10:10:23 PM UTC-5, [email protected] wrote:

Hi Jim -

I ran into the same problem today - where I was inserting into/updating a data table based on user interactions on a plot. The table data source ends up getting out of sync w/ the plot and plot data source. I’ll dig into this tomorrow and respond to your GH issue.

On Wednesday, January 6, 2016 at 9:37:43 PM UTC-6, Jim Sharpe wrote:

After looking through all the Bokeh references I can find I haven’t found an answer to this so I thought I’d post here.

I’m trying to find a way to query the values on selected rows of a DataTable after it has been sorted by clicking on one of the column headers.

Before the table row order gets modified by the sort operation I could use the selected indexes available in a CustomJS callback to get the values contained in the selected rows from the ColumnDataSource used as input to the table. However, when the table rows are reordered with a sort those selection indexes relate to the new order of the rows that are displayed. (i.e. the order oder of the source stays the same but the display order is different.) The reported selection indexes correctly match the display order (e.g. if the third row is selected a selection index of 2 will be reported). However, I can’t figure out how to get the values that are displayed on that row since it now isn’t the third row of the input data source.

I’m sure this must be more simple than I’m trying to make it, any suggestions would be greatly appreciated.

11

as a follow up, I noticed that the Javascript source.data has the displayed order but the python source.data has the original order … which is the disconnect.

I can see this using a JS callback and writing to the console.

I can barely function with JS, which is why I like bokeh, so is there a simple way to send the Javascript value back to Python?

If not simple … how about a complicated way?

thanks,

  • john
···

On Wednesday, February 1, 2017 at 5:00:14 PM UTC-5, [email protected] wrote:

I am having what I think is the exact issue discussed in this thread,
that is, I want to know what row a user selected in a table

but after interactive sorting the table and the returned indices are out of synch

Is there a fix or work around for this?

Is there any way to know the last header column used for sorting?

thanks,

  • john

On Thursday, February 18, 2016 at 10:10:23 PM UTC-5, [email protected] wrote:

Hi Jim -

I ran into the same problem today - where I was inserting into/updating a data table based on user interactions on a plot. The table data source ends up getting out of sync w/ the plot and plot data source. I’ll dig into this tomorrow and respond to your GH issue.

On Wednesday, January 6, 2016 at 9:37:43 PM UTC-6, Jim Sharpe wrote:

After looking through all the Bokeh references I can find I haven’t found an answer to this so I thought I’d post here.

I’m trying to find a way to query the values on selected rows of a DataTable after it has been sorted by clicking on one of the column headers.

Before the table row order gets modified by the sort operation I could use the selected indexes available in a CustomJS callback to get the values contained in the selected rows from the ColumnDataSource used as input to the table. However, when the table rows are reordered with a sort those selection indexes relate to the new order of the rows that are displayed. (i.e. the order oder of the source stays the same but the display order is different.) The reported selection indexes correctly match the display order (e.g. if the third row is selected a selection index of 2 will be reported). However, I can’t figure out how to get the values that are displayed on that row since it now isn’t the third row of the input data source.

I’m sure this must be more simple than I’m trying to make it, any suggestions would be greatly appreciated.

12

Hi,

I believe this is this open issue (please correct me if I have misunderstood):
  
  Getting values of selected rows from a DataTable after reordering with sort · Issue #3564 · bokeh/bokeh · GitHub

I've added it to the 0.12.6 milestone.

Thanks,

Bryan

···

On Feb 1, 2017, at 4:23 PM, [email protected] wrote:

as a follow up, I noticed that the Javascript source.data has the displayed order but the python source.data has the original order ... which is the disconnect.

I can see this using a JS callback and writing to the console.

I can barely function with JS, which is why I like bokeh, so is there a simple way to send the Javascript value back to Python?
If not simple ... how about a complicated way?

thanks,
   - john

On Wednesday, February 1, 2017 at 5:00:14 PM UTC-5, send2j...@gmail.com wrote:
I am having what I think is the exact issue discussed in this thread,
that is, I want to know what row a user selected in a table
but after interactive sorting the table and the returned indices are out of synch

Is there a fix or work around for this?

Is there any way to know the last header column used for sorting?

thanks,
   - john

On Thursday, February 18, 2016 at 10:10:23 PM UTC-5, lcan...@continuum.io wrote:
Hi Jim -

I ran into the same problem today - where I was inserting into/updating a data table based on user interactions on a plot. The table data source ends up getting out of sync w/ the plot and plot data source. I'll dig into this tomorrow and respond to your GH issue.

On Wednesday, January 6, 2016 at 9:37:43 PM UTC-6, Jim Sharpe wrote:
After looking through all the Bokeh references I can find I haven't found an answer to this so I thought I'd post here.

I'm trying to find a way to query the values on selected rows of a DataTable after it has been sorted by clicking on one of the column headers.

Before the table row order gets modified by the sort operation I could use the selected indexes available in a CustomJS callback to get the values contained in the selected rows from the ColumnDataSource used as input to the table. However, when the table rows are reordered with a sort those selection indexes relate to the new order of the rows that are displayed. (i.e. the order oder of the source stays the same but the display order is different.) The reported selection indexes correctly match the display order (e.g. if the third row is selected a selection index of 2 will be reported). However, I can't figure out how to get the values that are displayed on that row since it now isn't the third row of the input data source.

I'm sure this must be more simple than I'm trying to make it, any suggestions would be greatly appreciated.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/baf85184-4f94-4539-af8a-ffd3f8699499%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.