Proposal: Add `path` column to categories table as `ltree` type to make tree traversing easier #1122

erewok · 2017-10-11T15:09:21Z

Description

This is a proposal inspired by tickets (1, and 2) with the goal of eventually revealing more information about categories on pages where category information is available. It is also motivated by the current application code surrounding categories, which contains lots of SQL with operations like this: split_part(c2.slug, '::', 1).

This PR is intended as a suggestion for what to do with the categories table.

Following are changes included here:

Adds a path column as a Postgresql ltree type to the categories table in order to more easily query trees of categories and subcategories. This allows navigating trees of arbitrary depth and potentially more ergonomic path-finding queries.
Adds a parent_categories method to Category, which returns parent categories in order of traversal from root to this node.

Trade-offs to this Approach

Pros

Easily handle trees of arbitrary depth, ex: "category::sub-category::sub-catgeory-A::sub-category-A-1".
Makes queries to find a whole tree of nodes simpler (and possibly quicker?). Ex:
select slug, path from categories where path <@ 'root.web_programming';
Makes finding all root-level nodes simpler (assuming one is cool with the syntax). Ex:
select slug, path from categories where path ~ 'root.*{1}';
Makes finding the direct path from the root node to a particular node easier (see parent_categories method). Ex:
select slug, path from categories where path @> 'root.web_programming.http_client' order by path;
Invisible to current application code: nothing needs to be updated to handle the path column because it happens via database triggers. (This could also be a con depending on one's perspective.)

Cons

Postgresql only (harder to switch databases in the future)
Makes certain characters in slugs disallowed: [',",-]. Path labels must consist of "A-Za-z0-9_" separated by "." We swap - for _ and :: for . in the included Postgresql procedure.
This path column is nowhere in application code, so this is all hand-written SQL (but the current solution is doing that as well).
Error messages are opaque if you happen to have a bad character in a slug:

cargo_registry=# update categories set slug = 'test-new::bla$bla-::parent::child' where slug = 'test-new::parent::child';
ERROR:  syntax error at position 17
CONTEXT:  PL/pgSQL function set_category_path_to_slug() line 3 at assignment

Notes

Needs a test for the parent_categories method.

vignesh-sankaran · 2017-10-13T01:19:46Z

src/category.rs

@@ -161,6 +162,24 @@ impl Category {
        ).bind::<Text, _>(&self.category)
            .load(conn)
    }
+
+    pub fn parent_categories(&self, conn: &PgConnection) -> QueryResult<Vec<Category>> {


Could you add a doc comment here outlining what this function does?

You know I thought I had done that but I forgot about the three-slashes thing. Sorry about that.

kivikakk · 2017-10-17T03:42:09Z

I've now adapted #1130 into this PR! Parent category traversal is now easier (and accounts for arbitrary category tree depth).

carols10cents · 2017-10-18T15:24:33Z

Sorry this has taken me so long to look at-- my first impression is WHERE HAS LTREE BEEN ALL MY LIFE?!!?!? Like seriously, is this new? If not, I am irrationally angry at everyone i've interacted with who has known about this feature and not told me about it. I'm now going to start telling people as soon as I meet them-- "Hi, I'm Carol, have you heard about Postgres' ltree?"

Digging into the code and trying this out now :)

erewok · 2017-10-18T15:55:10Z

@carols10cents ltree has been part of Postgresql since at least 2004, I think. I only found out about it in the last couple of years and I have been surprised how rarely people recommend it or even know about it because it seems like a surprisingly useful data type. My theory is that Postgresql offers so many different options that it's difficult to actually know about all of them. For instance, I'm only aware of a handful of the myriad index types and I feel like I don't hear mention of those either.

The syntax, perhaps, takes a bit to get used to, but I find it pretty ergonomic myself:

@> some_path: means a path that's greater than or equal to some_path.
<@ some_path: means a path that's less than or equal to some_path.
~ some_path: looks sort of like a regex comparison, usually?

In this PR, I added root. to all the constructed paths, and this makes path-finding a whole lot easier (as long as no one ever adds a new category with a slug called root!) because you can find all top-level categories by simply querying all categories where the path is a direct descendent of root.. That looks like this:

select * from categories where path ~ 'root.*{1}';

carols10cents

This looks great, and it's working great too! The migration worked, adding crates to categories worked, adding new categories to categories.toml and restarting the server worked!

I also like how this easily enabled the parent category links!!

The only reason I'm not going to merge this right now is that when I generated the schema after running the migration, by running diesel print-schema --with-docs > src/schema.rs, I couldn't then use that schema because diesel doesn't define an Ltree type (for the type that it happily prints out).

I've filed a bug over in diesel's repo: diesel-rs/diesel#1262 and we'll see what they say :)

Thank you for this work, both of you!!!!

carols10cents · 2017-10-18T16:45:15Z

migrations/2017-10-08-193512_category_trees/up.sql

+
+-- Create some indices that allow us to use GIST operators: '@>', etc
+CREATE INDEX path_gist_categories_idx ON categories USING GIST(path);
+CREATE INDEX path_categories_idx ON categories USING btree(path);


Is there a reason to have both a gist and a btree index? The postgres docs say:

F.21.3. Indexes
ltree supports several types of indexes that can speed up the indicated operators:

B-tree index over ltree: <, <=, =, >=, >

GiST index over ltree: <, <=, =, >=, >, @>, <@, @, ~, ?

which looks like gist indexes take care of the same operators that btree indexes take care of?

All of this is probably moot anyway since the categories table is so smalll :)

Honestly, I've just seen everyone do it that way, so I figured it was a best practice, if not necessary.

carols10cents · 2017-10-18T16:49:34Z

app/templates/category/index.hbs

@@ -1,8 +1,11 @@
 {{ title category.category ' - Categories' }}

 <div id='crates-heading'>
-    {{svg-jar "crate"}}
-    <h1>{{ category.category }}</h1>
+    {{#link-to "categories"}}{{svg-jar "crate"}}{{/link-to}}


Neat easter-egg :)

erewok · 2017-10-18T17:34:05Z

thanks @carols10cents and thanks to @kivikakk for working on the frontend.

One thing I considered was rewriting the other queries that do split_part(some_value, "::", 1) in order for them to be all be consistent. I didn't do that because I wasn't sure if there would be buy-in for these changes. I knew there would be an issue with diesel, and I didn't want to rock the boat too much, even though I felt like this would be a useful direction to go in.

sgrif · 2017-10-18T19:28:33Z

You can just delete the path column from schema.rs, or create struct Ltree; somewhere and use it at the top of the table declaration.

kivikakk · 2017-10-19T07:15:28Z

It looks like print-schema won't automatically do what we want with extensions (going by this and #1133).

I've created a super basic diesel_ltree crate with an Ltree struct that does what we want (i.e. almost nothing right now), and manually added it to schema.rs in b7c49f8.

(Feel free to back this commit out if we don't want this after all.)

kivikakk · 2017-10-20T08:25:23Z

@erewok

One thing I considered was rewriting the other queries that do split_part(some_value, "::", 1) in order for them to be all be consistent. I didn't do that because I wasn't sure if there would be buy-in for these changes. I knew there would be an issue with diesel, and I didn't want to rock the boat too much, even though I felt like this would be a useful direction to go in.

diesel_ltree now supports the common operators and functions on ltrees/lqueries, so we could indeed redo those idiomatically from here on out.

sgrif · 2017-10-22T22:51:58Z

@kivikakk diesel_ltree needs to use http://docs.diesel.rs/diesel/pg/struct.PgMetadataLookup.html#method.lookup_type for its HasSqlType impls. Types from extensions do not have stable OIDs. I suspect that the only reason this isn't breaking things is because you aren't currently dealing with bind params of those types

kivikakk · 2017-10-26T07:59:26Z

Using latest ltree which fixes this. 👍 Thanks sgrif.

kivikakk · 2018-01-24T06:07:19Z

@carols10cents This is brought up to speed with master; would you mind taking another look? Just got an accessibility violation to clear up.

sgrif · 2018-01-24T20:05:34Z

src/category.rs

+        use diesel::sql_types::Text;
+
+        sql_query(
+            "SELECT c.id, c.category, c.slug, c.description, \


Can we move this whole thing into a .sql file and use include_str!, add some more newlines and indentation? The whole thing is very hard to parse. It's not obvious where the call to COALESCE ends for example

sgrif · 2018-01-24T20:06:48Z

src/category.rs

+    #[test]
+    fn category_parent_categories_includes_path_to_node_with_count() {
+        let conn = pg_connection();
+        conn.batch_execute(


Can we use Diesel's public API for this? (I need to update the other tests). You can write this as

insert_into(categories) .values(vec![ (category.eq("Cat 1"), slug.eq("cat1"), crates_cnt.eq(1)), ... ])

Done this (and fixed up the other tests too).

sgrif · 2018-01-24T20:07:20Z

src/lib.rs

@@ -5,7 +5,7 @@
 //! [krate](krate/index.html), [user](user/index.html) and [version](version/index.html) modules.
 #![deny(warnings)]
 #![deny(missing_debug_implementations, missing_copy_implementations)]
-#![recursion_limit = "128"]
+#![recursion_limit = "256"]


Why was this necessary?

Without:

error: recursion limit reached while expanding the macro `table_body` --> src/schema.rs:223:1 | 223 | / table! { 224 | | use diesel_full_text_search::{TsVector as Tsvector}; 225 | | use diesel_ltree::Ltree; 226 | | use diesel::sql_types::*; ... | 322 | | } 323 | | } | |_^ | = help: consider adding a `#![recursion_limit="256"]` attribute to your crate = note: this error originates in a macro outside of the current crate error: Could not compile `cargo-registry`.

kivikakk · 2018-01-25T01:56:57Z

error[E0063]: missing field `parent_categories` in initializer of `category::EncodableCategoryWithSubcategories`
   --> src/category.rs:526:19
    |
526 |         let cat = EncodableCategoryWithSubcategories {
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `parent_categories`

There is no line 526 of category.rs? The ~~same~~ similar line where it actually exists does have a parent_categories? The line as highlighted has not existed in any parent of the current branch? Travis what are you doing

~~I'll try amend committing to get a different SHA and force push.~~

git fetch wasn't updating the right remote nEVER MIND

erewok · 2018-01-25T02:59:32Z

nice work @kivikakk. I was actually wondering about this PR the other day. Thank you for continuing to push it forward.

kivikakk · 2018-02-01T05:47:17Z

Brought this back up to date.

sgrif · 2018-02-03T23:10:33Z

src/models/category.rs

-             WHERE split_part(c.slug, '::', 1) = c.slug
-             GROUP BY c.id
+        sql_query(format!(
+            "SELECT c.id, c.category, c.slug, c.description, \


How would you feel about moving this into a separate file and include_str!ing it. We can also change this to call .bind rather than using string interpolation (other than the order by)

kivikakk · 2018-02-21T06:16:20Z

Thank you for the ✅, sgrif!

Let me know if there's anything else to be done to get this merged, if we're still happy with it.

carols10cents · 2018-03-15T00:28:33Z

Thank you @erewok and @kivikakk for keeping this up to date, and sorry for the delay!

I tested this out and it looks like it's working great in the UI!

Buuuuut I noticed in the schema.rs that path was added as a column on the crates table, but if anything, it should be added to the categories table... but if I add it to the categories table by running diesel print-schema --with-docs > src/schema.rs and then manually adding use diesel_ltree::Ltree; within the table! call for categories (i.e. this commit) I then get errors, a bunch like this:

error[E0412]: cannot find type `Int4` in this scope
  --> src/schema.rs:83:15
   |
83 |         id -> Int4,
   |               ^^^^ did you mean `Into`?

So then I added use diesel::sql_types::*; in this commit to be more like the crates table!, which has custom types and works.

That gets rid of ~15 errors, but leaves me with 4 that look like this:

error[E0277]: the trait bound `(i32, std::string::String, std::string::String, std::string::String, i32, chrono::NaiveDateTime): diesel::Queryable<(diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Timestamp, diesel_ltree::Ltree), _>` is not satisfied
  --> src/controllers/category.rs:42:10
   |
42 |         .first::<Category>(&*conn)?;
   |          ^^^^^ the trait `diesel::Queryable<(diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Timestamp, diesel_ltree::Ltree), _>` is not implemented for `(i32, std::string::String, std::string::String, std::string::String, i32, chrono::NaiveDateTime)`

which, ok, the Category struct that's Queryable doesn't have the path column specified.

I tried adding path as type LTree in this commit, but then I get these errors:

error[E0277]: the trait bound `diesel_ltree::Ltree: diesel::Queryable<diesel_ltree::Ltree, diesel::pg::Pg>` is not satisfied
  --> src/controllers/category.rs:42:10
   |
42 |         .first::<Category>(&*conn)?;
   |          ^^^^^ the trait `diesel::Queryable<diesel_ltree::Ltree, diesel::pg::Pg>` is not implemented for `diesel_ltree::Ltree`
   |

The tests in diesel_ltree use Queryable with the path column as type String, so I tried that too in this commit, but then I get these errors:

error[E0277]: the trait bound `*const str: diesel::deserialize::FromSql<diesel_ltree::Ltree, diesel::pg::Pg>` is not satisfied
  --> src/controllers/category.rs:42:10
   |
42 |         .first::<Category>(&*conn)?;
   |          ^^^^^ the trait `diesel::deserialize::FromSql<diesel_ltree::Ltree, diesel::pg::Pg>` is not implemented for `*const str`
   |
   = help: the following implementations were found:
             <*const [u8] as diesel::deserialize::FromSql<diesel::sql_types::Binary, DB>>
             <*const str as diesel::deserialize::FromSql<diesel::sql_types::Text, DB>>

soooo @sgrif @kivikakk am I using diesel or diesel_ltree wrong? or is there something incompatible/missing here?

* Add migration for ltree path column on categories table * Add "ancestors" property to categories/:category_id endpoint

Not sure why this is needed exactly, but the crates table does this sooo

This is necessary because: - The path column is of type Ltree - To get text out of an ltree column, it has to be selected using the postgres function ltree2text - We can't modify the select statement generated by the table! macro to select columns with type ltree differently - So we'd have to explicitly select columns for all Category queries anyway - But we never use categories.path, only query against it, so save all this trouble and just never select it in the same way Crate never selects the fulltext search columns. There might be better ways to do this, or at the very least a better way of defining the type aliases, but this is what I got working.

carols10cents · 2018-06-26T02:33:11Z

Ok, I think I've successfully figured this one out. It worked when the path column was accidentally on the crates table because the crates code was already explicitly selecting fewer than all columns; when the path column was added to the category table in the schema instead, the same don't-select-all-columns code needed to happen for category too.

@sgrif if you have a minute, could you review the "Explicitly never select categories.path column" commit of mine and make sure i did this right?

kivikakk · 2018-08-10T05:14:41Z

It'd be nice if we could land this!

carols10cents · 2018-08-22T22:45:56Z

Yes, yes it would. YOLO

bors: r+

carols10cents · 2018-08-29T23:03:06Z

hMMMM why didn't that work....

bors: r+

1122: Proposal: Add `path` column to categories table as `ltree` type to make tree traversing easier r=carols10cents a=erewok ## Description This is a proposal inspired by tickets ([1](#1093), and [2](#721)) with the goal of eventually revealing more information about categories on pages where category information is available. It is also motivated by the current application code surrounding categories, which contains lots of SQL with operations like this: `split_part(c2.slug, '::', 1)`. This PR is intended as a suggestion for what to do with the `categories` table. Following are changes included here: - Adds a `path` column as a Postgresql `ltree` type to the `categories` table in order to more easily query trees of categories and subcategories. This allows navigating trees of arbitrary depth and potentially more ergonomic path-finding queries. - Adds a `parent_categories` method to `Category`, which returns parent categories _in order of traversal_ from root to this node. ## Trade-offs to this Approach ### Pros - Easily handle trees of arbitrary depth, ex: "category::sub-category::sub-catgeory-A::sub-category-A-1". - Makes queries to find a whole tree of nodes simpler (and possibly quicker?). Ex: `select slug, path from categories where path <@ 'root.web_programming';` - Makes finding all root-level nodes simpler (assuming one is cool with the syntax). Ex: `select slug, path from categories where path ~ 'root.*{1}';` - Makes finding the direct path from the root node to a particular node easier (see `parent_categories` method). Ex: `select slug, path from categories where path @> 'root.web_programming.http_client' order by path;` - Invisible to current application code: nothing needs to be updated to handle the `path` column because it happens via database triggers. (This could also be a _con_ depending on one's perspective.) ### Cons - Postgresql only (harder to switch databases in the future) - Makes certain characters in slugs disallowed: `[',",-]`. Path labels must consist of "A-Za-z0-9_" separated by "." We swap `-` for `_` and `::` for `.` in the included Postgresql procedure. - This `path` column is nowhere in application code, so this is all hand-written SQL (but the current solution is doing that as well). - Error messages are opaque if you happen to have a bad character in a slug: ``` cargo_registry=# update categories set slug = 'test-new::bla$bla-::parent::child' where slug = 'test-new::parent::child'; ERROR: syntax error at position 17 CONTEXT: PL/pgSQL function set_category_path_to_slug() line 3 at assignment ``` ## Notes - [x] Needs a test for the `parent_categories` method. Co-authored-by: Erik Aker <[email protected]> Co-authored-by: Ashe Connor <[email protected]> Co-authored-by: Carol (Nichols || Goulding) <[email protected]>

carols10cents · 2018-08-29T23:03:36Z

there we go. good bot!

bors-voyager · 2018-08-29T23:28:01Z

Build failed

continuous-integration/travis-ci/push

…erimental

carols10cents · 2018-08-30T15:15:56Z

hmmmm looks like rustfmt had differences and clippy failed to install? i get different results when running rustfmt locally, fun. we'll see if this fixes it

carols10cents · 2018-08-30T19:35:32Z

ok let's try this one more time!

bors: r+

1122: Proposal: Add `path` column to categories table as `ltree` type to make tree traversing easier r=carols10cents a=erewok ## Description This is a proposal inspired by tickets ([1](#1093), and [2](#721)) with the goal of eventually revealing more information about categories on pages where category information is available. It is also motivated by the current application code surrounding categories, which contains lots of SQL with operations like this: `split_part(c2.slug, '::', 1)`. This PR is intended as a suggestion for what to do with the `categories` table. Following are changes included here: - Adds a `path` column as a Postgresql `ltree` type to the `categories` table in order to more easily query trees of categories and subcategories. This allows navigating trees of arbitrary depth and potentially more ergonomic path-finding queries. - Adds a `parent_categories` method to `Category`, which returns parent categories _in order of traversal_ from root to this node. ## Trade-offs to this Approach ### Pros - Easily handle trees of arbitrary depth, ex: "category::sub-category::sub-catgeory-A::sub-category-A-1". - Makes queries to find a whole tree of nodes simpler (and possibly quicker?). Ex: `select slug, path from categories where path <@ 'root.web_programming';` - Makes finding all root-level nodes simpler (assuming one is cool with the syntax). Ex: `select slug, path from categories where path ~ 'root.*{1}';` - Makes finding the direct path from the root node to a particular node easier (see `parent_categories` method). Ex: `select slug, path from categories where path @> 'root.web_programming.http_client' order by path;` - Invisible to current application code: nothing needs to be updated to handle the `path` column because it happens via database triggers. (This could also be a _con_ depending on one's perspective.) ### Cons - Postgresql only (harder to switch databases in the future) - Makes certain characters in slugs disallowed: `[',",-]`. Path labels must consist of "A-Za-z0-9_" separated by "." We swap `-` for `_` and `::` for `.` in the included Postgresql procedure. - This `path` column is nowhere in application code, so this is all hand-written SQL (but the current solution is doing that as well). - Error messages are opaque if you happen to have a bad character in a slug: ``` cargo_registry=# update categories set slug = 'test-new::bla$bla-::parent::child' where slug = 'test-new::parent::child'; ERROR: syntax error at position 17 CONTEXT: PL/pgSQL function set_category_path_to_slug() line 3 at assignment ``` ## Notes - [x] Needs a test for the `parent_categories` method. Co-authored-by: Erik Aker <[email protected]> Co-authored-by: Ashe Connor <[email protected]> Co-authored-by: Carol (Nichols || Goulding) <[email protected]>

bors-voyager · 2018-08-30T19:48:43Z

Build succeeded

continuous-integration/travis-ci/push

kivikakk · 2018-08-30T23:21:46Z

Yay!! ✨

kivikakk · 2018-08-30T23:22:01Z

@carols10cents Thank you so much for pushing this through!

sgrif · 2018-08-30T23:22:21Z

🎉

carols10cents · 2018-08-31T00:50:34Z

You're welcome! I'll try and get this deployed tomorrow :)

…

On Thu, Aug 30, 2018 at 7:22 PM Sean Griffin ***@***.***> wrote: 🎉 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1122 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAL1UgEdWb-pcjhb9mnb9CxJuwIRx_UJks5uWHOugaJpZM4P1pHZ> .

erewok · 2018-09-04T18:17:36Z

Wow, nice work all. I completely forgot about this PR (sorry about that) and found it just now in my github unread.

erewok changed the title ~~Proposal: Add path column as ltree type to make tree traversing easier~~ Proposal: Add path column to categories table as ltree type to make tree traversing easier Oct 11, 2017

carols10cents added the S-waiting-on-review label Oct 11, 2017

vignesh-sankaran suggested changes Oct 13, 2017

View reviewed changes

erewok mentioned this pull request Oct 16, 2017

Link to parent category from category page #1130

Closed

carols10cents mentioned this pull request Oct 18, 2017

Support postgress ltree type in schema diesel-rs/diesel#1262

Closed

1 task

carols10cents reviewed Oct 18, 2017

View reviewed changes

carols10cents added S-waiting-on-author and removed S-waiting-on-review labels Oct 25, 2017

sgrif reviewed Jan 24, 2018

View reviewed changes

sgrif reviewed Feb 3, 2018

View reviewed changes

sgrif approved these changes Feb 3, 2018

View reviewed changes

erewok added 2 commits June 20, 2018 20:04

New categories path column as ltree type

7350391

* Add migration for ltree path column on categories table * Add "ancestors" property to categories/:category_id endpoint

Add test and doc function for parent_categories

876bd05

kivikakk and others added 5 commits June 20, 2018 23:15

master merge fixup

6f4a396

extract some more SQL

e3c3625

Add path column to categories table

a5c9f14

Add sql_types to categories' table! in the schema

6240588

Not sure why this is needed exactly, but the crates table does this sooo

carols10cents added S-waiting-on-review and removed S-waiting-on-author labels Jun 26, 2018

Commit package lock changes

13a1f9c

Merge remote-tracking branch 'upstream/master' into category_tree_exp…

4434413

…erimental

carols10cents added 2 commits August 30, 2018 14:26

Cargo fmt

8e099ed

Fix Cargo.lock

81dff1e

bors-voyager bot merged commit 81dff1e into rust-lang:master Aug 30, 2018

kivikakk deleted the category_tree_experimental branch August 30, 2018 23:21

jtescher mentioned this pull request Oct 20, 2019

Provide link to parent category #1093

Closed

Proposal: Add path column to categories table as ltree type to make tree traversing easier #1122

Proposal: Add path column to categories table as ltree type to make tree traversing easier #1122

Uh oh!

Conversation

erewok commented Oct 11, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Trade-offs to this Approach

Pros

Cons

Notes

Uh oh!

vignesh-sankaran Oct 13, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kivikakk commented Oct 17, 2017

Uh oh!

carols10cents commented Oct 18, 2017

Uh oh!

erewok commented Oct 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

carols10cents left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

erewok commented Oct 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sgrif commented Oct 18, 2017

Uh oh!

kivikakk commented Oct 19, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kivikakk commented Oct 20, 2017

Uh oh!

sgrif commented Oct 22, 2017

Uh oh!

kivikakk commented Oct 26, 2017

Uh oh!

kivikakk commented Jan 24, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgrif Jan 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kivikakk commented Jan 25, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

erewok commented Jan 25, 2018

Uh oh!

kivikakk commented Feb 1, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kivikakk commented Feb 21, 2018

Uh oh!

carols10cents commented Mar 15, 2018

Uh oh!

carols10cents commented Jun 26, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Proposal: Add `path` column to categories table as `ltree` type to make tree traversing easier #1122

Proposal: Add `path` column to categories table as `ltree` type to make tree traversing easier #1122

erewok commented Oct 11, 2017 •

edited

Loading

vignesh-sankaran Oct 13, 2017 •

edited

Loading

erewok commented Oct 18, 2017 •

edited

Loading

erewok commented Oct 18, 2017 •

edited

Loading

kivikakk commented Oct 19, 2017 •

edited

Loading

sgrif Jan 24, 2018 •

edited

Loading

kivikakk commented Jan 25, 2018 •

edited

Loading

carols10cents commented Jun 26, 2018 •

edited

Loading