Using scope ordering by type

[rossme]

Hi @brendon, I've been using acts_as_list using a scope similar to this one below:

    TYPES = [
      Item::Foo.name,
      Item::Bar.name
    ].freeze

    acts_as_list scope: [:list_id, discarded_at: nil, type: TYPES]

As you know, this ensures that the position order is updated if the item type is included in TYPES. When I looked at Positioning, it wasn't clear to me that this functionality is supported, at least from a brief review of Positioning::Behaviour. Any idea if it already is (and I completely missed it) or if it will be in a future release of Positioning?

Thanks

[brendon]

Hi @rossme, that's an interesting one. This has come up before in a more boolean kind of way where someone wanted to only order things where something was like enabled: true.

In positioning, everything boils down to SQL queries for a scope so I'm wondering how we could achieve this in your example. Perhaps you could have a method called types that either returned [Item::Foo.name, Item::Bar.name] if [Item::Foo.name, Item::Bar.name].include? type or false if not. There are extra things to consider here too like change detection. With this solution one of the scope 'attributes' would... actually forget all that, it probably won't work because of the separation of the column and the value we're looking for.

I'll have a look and see if this is straightforward to implement in positioning. I don't think it'd be too hard. It's essentially a boolean column with a custom definition for what's true. You'd still get items that aren't those types being positioned because in positioning everything is positioned but you could just ignore those positions.

Let me ponder, and if you feel like having a crack at it, please go ahead by all means :D

[rossme]

Thanks for the comments @brendon, I'll have a play with this later on today and see where I end up!

[brendon]

As a side note, I needed to do something like this and ended up using a virtual column:

t.virtual "absolute_section_id", type: :bigint, as: "coalesce(`section_id`,0)", stored: true

I sometimes had articles belonging to sections but also there were lead articles that weren't in a section so they had a NULL section_id. I coalesced that to 0 so that those articles could be ordered as if they were in the same scope. I can't remember why NULL wasn't an option for the scope.

[brendon]

Thanks for looking into that deeper @rossme :) I think that approach might complicate things a bit too much unfortunately. I think it would be best to allow for hashes in the positioned definition as you originally proposed. A hash would then basically define a boolean condition that will segment the list that way. The value part could be a single value or an array, just anything that ActiveRecord accepts and it will either match or not. That's my simplistic thinking on it anyway, it might fall apart in the implementation.

I don't really want to walk into the zone of allowing the position column to be NULL at all as that will break the constraint we recommend having. All rows in the table must belong to a scope.

I'll have a play with the code and see what comes of it :D

[brendon]

I'm not having much luck thinking of a clean solution to this. Can you give me more of your real-world requirement to only have two of your STI types mean that an item belongs to a particular list?

[brendon]

Having pondered it slightly longer, it might be most easily solved by you adding a couple of extra columns to your table: discarded and interesting_type (or whatever you want to call it). You could make both booleans. Then intercept the assignment of the values you're potentially changing so you can update the value of these columns:

def discarded_at=(value)
  this.discarded = !value.nil?
  super
end

def type=(value)
  this.interesting_type = TYPES.include?(value)
  super
end

Then you can just do positioned on: [:list, :discarded, :interesting_type].

It's a little messy but as I work through how this could be abstracted into positioning I can't really see a tidy way that doesn't push me into a corner in the future because it's such an open-ended requirement. It always boils down to the scope needing to be able to be reflected in SQL while at the same time needing to detect a scope change in rails. This is easy if you use hard database columns :)

[rossme]

Hi @brendon thanks for looking into this specific use case, we actually semi-solved it following your original example by using a virtual column. Discard is easily solved as we can just pass the column discarded_at as a param. The virtual column has a boolean and we ignore certain types at a Postgres level, instead of passing the types to positioning (which is what we were able to do with acts_as_list. It's not ideal but it makes use of the gem as it is, and I appreciate that it's a pain in the ass to adapt features (or introduce new ones) for 1 unique use-case.

[brendon]

Haha! Indeed. Yes a virtual column would be perfect except that I can't detect changes to that and so I can't move an item in and out of scope for you as it changes. Doing it in Ruby would get around that limitation.