https://linen.dev logo
Join Slack
Powered by
what do folks thing about applying an ordering to ...
# contributing-to-airbyte
c
what do folks thing about applying an ordering to how the fields of the spec are exposed in the UI? the common issue we have is for say, the postgres spec, in the UI password appears before username. This is because all of these properties are effectively in a map so we don't get any order guarantees. i would like a way to describe the order of the fields. e.g. for postgres i think the most approach form is host, port, database, username, password.
u
we should definitely have that
u
also I’m not sure why some of those fields are capitalized and others aren’t
u
The only way i can figure doing it by using a custom field in the jsonscehma
u
Copy code
"username": {
  "description": "Username to use to access the database.",
  "type": "string",
  "order": 1
},
"password": {
  "description": "Password associated with the username.",
  "type": "string",
  "airbyte_secret": true,
  "order": 2
},
u
^ you have any better idea than this?
u
I think that makes sense
u
only other way to do it would be to have an ordered array of named fields?
u
https://airbytehq.slack.com/archives/C019WEENQRM/p1611181301056600?thread_ts=1611181239.056100&cid=C019WEENQRM i think this is governed by whether or nor the property has a title field. if no title field then it just takes the property name. title field allows for a "pretty" version.
u
I don’t think that’s true
u
there are no titles in the postgres spec.json
u
oh. huh. then i don't know.
u
there are a few flavors of this. in the body of the json schema object we could set order by doing :
Copy code
{
  "documentationUrl": "<https://docs.airbyte.io/integrations/destinations/postgres>",
  "supportsIncremental": true,
  "order": ["username", "password"],
  "properties": { ...
u
that version might be more pleasant to update
u
I support it! I think the “order” property on each field is less error prone
u
it prevents referencing non-existent fields
u
although I think this might get wonky with 
oneOf
s
u
that’s a good point
u
nested ordering
u
🤯
u
sounds like a not today problem.
u
I don't think that's true
@Jared Rhizor (Airbyte) Actually I believe thats how it is working now. Postgres doesn’t have title - so names are in lowercase. But the thing is, that initially we had some titles in locales configured, so that’s why you can see some names.
Copy code
"form.password": "Password",
  "form.dbname": "DB Name",
  "form.postgres_host": "Host",
  "form.postgres_port": "Port",
  "form.postgres_username": "User",
  "form.postgres_password": "Password",
  "form.postgres_database": "DB Name",
  "form.postgres_schema": "Schema",
Since that time our approach changed to the better one and probably you see here some mix of old concept and new one. We can actually better just remove those locales to keep it more clear
Copy code
const defaultLabel = formatMessage({
    id: `form.${fieldKey}`,
    defaultMessage: fieldKey
  });

  const label = `${property.title || defaultLabel}${
    property.isRequired ? " *" : ""
  }`;
u
ah ok
u
so it isn’t in the spec, it’s in the frontend
u
as for jsonschema - I would better aim to support default jsonschema as much as possible and do not add custom fields if it’s possible. Also as an option - we can return array of properties. Array always has definite order.
u
so it isn't in the spec, it's in the frontend
Well actually its more about the spec. If I remove those locales - our names will be in lower case and may even have a bit ugly naming ( before that we had 
postgres_database
, but I may be mistaken.
u
I think uppercasing the first letter by default fixes 90% of the cases
u
don’t think so. There are a lot of undersoce fields (
jdbc_url
, 
destination_path
) and for me something like 
Jdbc_url
looks much uglier in UI than 
jdbc_url
We may try to make some common flow - like PascalCase all snake_case and overwrite the ones we do not like with titles.
u
I think somewhere we must be injecting the name of the connector into the field name
u
in the actual spec for postgres it doesn’t have 
postgres_
prefixes
u
Do not worry about that ‘postgres’ prefix. I believe that prefix is frontend based. I was talking about snake cased fields
u
i agree with artem here. if we care about what the fields look like then we should be putting in the title. if we don't then the default seems like a fine compromise.
u
https://airbytehq.slack.com/archives/C019WEENQRM/p1611183357062700?thread_ts=1611181239.056100&amp;cid=C019WEENQRM is there a way to do this that his valid json schema? i thought the properties field always expected a map not a list, but perhaps i'm don't understand the json schema spec.
u
@charles I agree we should be putting it in the title, but right now it’s in the locale not the title, right?
u
Nope. We do not use locales anywhere except postgres and it is sort of legacy which we can remove.
u
oh ok
3 Views
Open in Slack
PreviousNext
Powered by