Graphql-engine: add operators for ltree columns

Created on 3 Oct 2018  路  9Comments  路  Source: hasura/graphql-engine

server quickfix good first issue help wanted enhancement medium

Most helpful comment

Thank you for your ongoing enhancements to Hasura. Do you have an ETA for this?

All 9 comments

Thank you for your ongoing enhancements to Hasura. Do you have an ETA for this?

That would be amazing! The current tree implementation is totally lacking https://blog.hasura.io/graphql-and-tree-data-structures-with-postgres-on-hasura-dfa13c0d9b5f/

This feature I would be a huge benefit for me. What does it mean for the triage/2-rfc-candidate label to be removed and dsandip to be unassigned?

Any ETA on this? This would be an incredibly powerful enhancement in queries as well as the permission rule builder to be able to respectively query and validate per hierarchical data.

The current way to handle searching / validation of hierarchical relationships in Hasura is cumbersome, antiquated, and does not readily allow arbitrary depth of nested relationships: https://hasura.io/blog/graphql-and-tree-data-structures-with-postgres-on-hasura-dfa13c0d9b5f/. The Postgres community recognized this same deficiency within itself years ago and put forward the ltree module which provides a data type (ltree path) and querying language to easily manage hierarchical relationships of arbitrary depth within a single table. It then becomes trivial using the accompanying query language to search for parents of children and children of parents.

Our software includes more than a half dozen core entities that are defined by hierarchical relationships (employee reporting relationships, certain job function permissions, facility groupings (per facility < region < district < country < territory < global), product containers, etc.) and our database relies heavily on ltrees to model these. I could easily point to dozens if not hundreds of other real-world examples of hierarchies that could all be modeled in a database using ltree: blog post-style comments and responses; organization hierarchies, permission hierarchies, directory-style hierarchies, etc. Without this support, any queries and permissions that would be interacting with such tables using ltrees would not be able to make sense of the hierarchy information and would thus need to be completely remodeled in these databases. I think a question for you guys is just how popular is ltree in Postgres. While I couldn't find usage metrics, here are some interesting data points:

Congratulations to all for the nice progress that Hasura is making lately!

If this is an easy fix could be implemented soon? We are also very interested in this feature, because we need to support a marketplace with a lot of categories and subcategories organized in ltree columns.

Congratulations to all for the nice progress that Hasura is making lately!

If this is an easy fix could be implemented soon? We are also very interested in this feature, because we need to support a marketplace with a lot of categories and subcategories organized in ltree columns.

I think we need to wait a couple more years for this feature to be implemented )))
@0x777 or I'm wrong?

Eagerly waiting for ltree support. Any ETA guidance would be nice so that we can plan accordingly. thanks.

Folks, we have few high priority features already in the queue for the next 2 releases. You can expect this in 3/4 releases from now. Hard to give ETA currently, unfortunately.

@tirumaraiselvan any updates on how this is being sequenced?

if not, are there any good examples of another data type being added that a contributor could follow?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bogdansoare picture bogdansoare  路  3Comments

stereobooster picture stereobooster  路  3Comments

tirumaraiselvan picture tirumaraiselvan  路  3Comments

marionschleifer picture marionschleifer  路  3Comments

cpursley picture cpursley  路  3Comments