MARXAN-545 MARXAN-644 specification repository

[kgajowy]

Substitute this line for a meaningful title for your changes

Overview

Please write a description. If the PR is hard to understand, provide a quick explanation of the code.

Designs

Link to the related design prototypes (if applicable)

Testing instructions

Please explain how to test the PR: ID of a dataset, steps to reach the feature, etc.

Feature relevant tickets

Link to the related task manager tickets

---

Checklist before submitting

• Meaningful commits and code rebased on develop.
• If this PR adds feature that should be tested for regressions when
  deploying to staging/production, please add brief testing instructions
  to the deploy checklist (docs/deployment-checklist.md)
• Update CHANGELOG file

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.

marxan – ./app

🔍 Inspect: https://vercel.com/vizzuality1/marxan/7T4EJvfNAxEPyHDx7NnGRUoMZsx2
✅ Preview: https://marxan-git-feat-marxan-545-marxan-644-specif-35051c-vizzuality1.vercel.app

marxan-storybook – ./app

🔍 Inspect: https://vercel.com/vizzuality1/marxan-storybook/EfT9hatCLnqaqW2wAwG2vKj9Ag8W
✅ Preview: https://marxan-storybook-git-feat-marxan-545-marxan-5c29b2-vizzuality1.vercel.app

[Dyostiq]

Suggested change

return;

[Dyostiq]

not true, it's varchar

[kgajowy]

Could be that actual state isn't matched to what we have in entity declaration - still wanted a short route just o keep migration-generation to return results.

[Dyostiq]

then it's better to update it to varchar :D

[Dyostiq]

the kept convention is to use plurals

[hotzevzl]

Since this is a full entity now, we will also need an order (or something like that) column to keep the ordering of features in a specification consistent with what API clients send (or the frontend to start with may see features jumping around depending on contingent factors such as order of insert/update in db)

[kgajowy]

@hotzevzl sorting on serializer/controller level should be enough, shouldn't it?

if it is needed at all (https://vizzuality.slack.com/archives/C01G7PRQB96/p1628593316134400)

[hotzevzl]

ok, so if we are echoing back (with any augmentation) the specification as received in the request payload then we don't need to keep an order of the children of specification_features as stored in db.

if we are composing the response from the data we have in db, then keeping the same order of geofeatures as provided in the request payload would be preferable for a consistent user experience - we could sort at serializer level, but without other order hints we could only order alphabetically here, unless I am misunderstanding what you suggest.

[hotzevzl]

Since this is a full entity now, we will also need an order (or something like that) column to keep the ordering of features in a specification consistent with what API clients send (or the frontend to start with may see features jumping around depending on contingent factors such as order of insert/update in db)