Support for filtering on columns

[christiaanwesterbeek]

A postgres view or table might have a bytea column. Or there might be a computed column on that table that calls a function to convert the bytea column to a data url (just as an example, but a real one in my case).

Using a GET_LIST on that view or table is going to be slow, really slow.

What I'd like to achieve is to pass to the dataProvider a column array that instructs ra-postgraphile to build a query for the resource requesting only those columns.

Here's how it may be used.

dataProvider(GET_LIST, 'some-table-with-bytea-column', {
    pagination: { page: 1, perPage: 25 },
    sort: { field: 'sequence', order: 'ASC' },
    filter: {},
    columns: ['id', 'name'], // <-- this is what I mean
});

But please tell me if there's another way that I can use to query only some fields of a resource.

[BowlingX]

Hi :) This makes absolute sense, I could add support to query only certain fields for certain types.

[BowlingX]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[christiaanwesterbeek]

Thanks for including this in the release. I tried it and what I understand is that we can add includeFields or excludeFields as part of options that can be supplied to the main method that creates the dataProvider. Here's my complete custom hook that returns my dataProvider.

import { useState, useEffect } from 'react';
import { useApolloClient } from '@apollo/react-hooks';
import pgDataProvider from 'ra-postgraphile';
import clientDecorator from './clientDecorator';

const extendedConfiguration = { // <-- This
    typeMap: {
        File: {
            excludeFields: ['dataUrl', 'binaryData'],
        },
    },
};

function useDataProvider() {
    const [dataProvider, setDataProvider] = useState(null);

    const client = useApolloClient();

    useEffect(() => {
        (async () => {
            const dataProvider = await pgDataProvider(
                client,
                extendedConfiguration // <-- Here
            );
            setDataProvider(() => clientDecorator(dataProvider));
        })();
    }, [client]);

    return dataProvider;
}

export default useDataProvider;

I thinks this means that the fields are included or excluded for every request on that resource. Is that correct?

What I need however is that a GET_LIST on the resource the large fields ('dataUrl' and 'binaryData') are excluded, but when I do a GET_ONE on the same resource, the fields are included (because I need to render the pdf now). I think it does make sense that an applications doesn't always need the same set of columns for each view...

For another web application I've built with a custom postgrest providers, I'm able to configure a request ad-hoc something like this.

import { Datagrid, List, TextField, DateField } from 'react-admin';

const permanentFilter = {
    __options: {
        excludeFields: ['dataUrl', 'binaryData']
    },
};

const FileList = props => {
    return (
        <List
            {...props}
            filter={permanentFilter} // <-- Here
        >
            <Datagrid rowClick="edit">
                <TextField source="name" />
                <DateField source="created" />
                <TextField source="mime" />
            </Datagrid>
        </List>
    );
};

@BowlingX What do you think of this solution? Do you see another approach? I rather not create a separate resource (one with and one without the large fields)...

[BowlingX]

Hi :),

you can currently either provide an array or a function for excludeFields. I can add a second argument to the function of what operation was used. This would let you implement custom logic to it and exclude them only in cases that makes sense for you :)

[BowlingX]

I also like passing an additional __options for the filters, I will consider it as an additional idea. I will for now add the second argument to the function.

[christiaanwesterbeek]

I suppose that would work too. Either as a second argument or let the first argument be an object, in case more arguments may be needed in the future.

[BowlingX]

I added it as a second argument, to prevent breaking changes.

[BowlingX]

🎉 This issue has been resolved in version 4.1.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀