Sort orders

[anthon]

Entities/relationships are always sorted by name, but what about media entities? Right now, afaict, there's no sort_by defined in the query. This becomes quite crucial as soon as you want to display anything like a gallery/slideshow.

If you'd like Medium to be treated more like a first-class entity, it should probably get a name field, and be sorted by that by default. And then we can add a ?sort_by=... to all the JSON API endpoints. :)

But ideally media entities would have a position field, and attached media can be sorted directly in the entity view within the admin interface, via drag/drop (future) or just a number. That would provide a lot of flexibility for future interfacing.

[moritzschepp]

To my experience its very rare, that you actually want to sort according to some attribute of a media entity (except created_at), because this sort order is always global to the current installation of ConedaKOR. Mostly, people are asking for a specific order from the viewpoint of a particular entity. For example: The order of media entities shown on the page of an artwork-entity. But generically speaking, this order is specific to the artwork-entity (the same media could be related to another entity in a different order). Therefore, the position field you are suggesting is a good idea but it needs to be an attribute of the (directed) relationship. It will be done (I don't find the legacy issue at the moment, but it exists within our previous bug tracker), but this is truly a new feature, so its not really a priority at the moment.

For sorting /entities.json, I can easily offer (by) name, created_at, updated_at, id, uuid, distinct_name, subtype. Same applies to /relationships.json and its variants. Would that help?

[anthon]

You're right – the sorting has to be attached to the relationship, and if there's an issue filed on this already then let's leave it.

For now I see a very simple solution: 'Additional properties'. The new inline attachment editor allows for very simple adding of custom props on the relationships, where sorting: 1 could be a perfect workaround for now.

But! Shouldn't 'Additional properties` be a key/value input?

[moritzschepp]

Properties on relationships are just values, no label. For now, we can't sort by those because they are serialized within a text column. Their purpose was originally to provide a way to add more descriptive content to relationships.

[anthon]

Yes, I'm aware of the attribute serialisation, but at the moment the "attributes" aren't really attributes, but a list of values; if they were key => value attributes, they can be sorted on the client. The case we're discussing relates to media entity relationships, and only really relevant in the #72 example. If, in a single entity request, it's possible to get all related (media) entities, it would be very easy to sort them in the display based on a position: n attribute. And that ability to sort is very crucial as soon as you want to display any kind of narrative situation.

[moritzschepp]

Oh I see. Can't you do a bit more magic on the client and then sorting works with the array? Something like

entity.properties[0].split(/\s+:\s/)[1]`

and then sort by the result? This would also get us around the issues that would come with migrating towards hashes/objects:

• people entered data as arrays already, how to migrate this?
• arrays provide order, hashes in ruby do as well (given the keys were added in the right order) and javascript (which renders everything) doesn't guarantee the order

In any case, please be aware that returning ALL related media for an entity is not possible beyond a cap, see #72.

[anthon]

You're right, the array can be used to sort the entites. I was just thinking about the future of KOR, and imagining that there might be requests for a way to add more properties to a relationship that can be retrieved through a key. Don't have a good example right now, though. And I'm not sure you want to give Relationships that much padding. Still, I think it would be a big addition for a relatively small effort.

people entered data as arrays already, how to migrate this?

Hm. I could imagine a translation, like value => value: value for those who've already been using it. But I don't know. How is the property array being used now? For what kind of values?

arrays provide order, hashes in ruby do as well (given the keys were added in the right order) and javascript (which renders everything) doesn't guarantee the order

Right. How is that a problem? Objects/hashes are already in use for entity properties..?

[moritzschepp]

What I have seen is people using it for further qualifying the relationship like in "Image - depicts -> house" where the relationship could have a property "view from east". Or when Images represent pages within books, then a property would hold the page number.

True, I can't think of a case (nor remember one) where the order does matter. One way to solve the first problem could also be to use a generic key for the legacy array values, so value => "legacy": value.

[anthon]

Both use cases would actually benefit from being keyed; view_direction: far east or page_number: 4. (Although in a clever data model the page number should probably be a property of the image, not the relationship.)

[moritzschepp]

... if it shows the whole page ;)

[anthon]

...or a page at all – some_entity > is_mentioned_in[page:2] > book, where "book" is just a pic of the cover.

[moritzschepp]

We just talked about this again and we thought it to be most straight forward to implement a position field on the relationships to make the order customizable.

For the keyed properties, we just created issue #240.