https://linen.dev logo
Channels
Powered by
c

charles

01/20/2021, 10:20 PM
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

user

01/20/2021, 10:21 PM
we should definitely have that
u

user

01/20/2021, 10:21 PM
also I’m not sure why some of those fields are capitalized and others aren’t
u

user

01/20/2021, 10:21 PM
The only way i can figure doing it by using a custom field in the jsonscehma
u

user

01/20/2021, 10:21 PM
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

user

01/20/2021, 10:21 PM
^ you have any better idea than this?
u

user

01/20/2021, 10:22 PM
I think that makes sense
u

user

01/20/2021, 10:22 PM
only other way to do it would be to have an ordered array of named fields?
u

user

01/20/2021, 10:23 PM
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

user

01/20/2021, 10:24 PM
I don’t think that’s true
u

user

01/20/2021, 10:24 PM
there are no titles in the postgres spec.json
u

user

01/20/2021, 10:24 PM
oh. huh. then i don't know.
u

user

01/20/2021, 10:24 PM
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

user

01/20/2021, 10:25 PM
that version might be more pleasant to update
u

user

01/20/2021, 10:27 PM
I support it! I think the “order” property on each field is less error prone
u

user

01/20/2021, 10:28 PM
it prevents referencing non-existent fields
u

user

01/20/2021, 10:28 PM
although I think this might get wonky with 
oneOf
s
u

user

01/20/2021, 10:29 PM
that’s a good point
u

user

01/20/2021, 10:29 PM
nested ordering
u

user

01/20/2021, 10:31 PM
🤯
u

user

01/20/2021, 10:37 PM
sounds like a not today problem.
u

user

01/20/2021, 10:54 PM
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

user

01/20/2021, 10:55 PM
ah ok
u

user

01/20/2021, 10:55 PM
so it isn’t in the spec, it’s in the frontend
u

user

01/20/2021, 10:55 PM
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

user

01/20/2021, 10:57 PM
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

user

01/20/2021, 11:00 PM
I think uppercasing the first letter by default fixes 90% of the cases
u

user

01/20/2021, 11:25 PM
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

user

01/20/2021, 11:29 PM
I think somewhere we must be injecting the name of the connector into the field name
u

user

01/20/2021, 11:30 PM
in the actual spec for postgres it doesn’t have 
postgres_
prefixes
u

user

01/20/2021, 11:32 PM
Do not worry about that ‘postgres’ prefix. I believe that prefix is frontend based. I was talking about snake cased fields
u

user

01/21/2021, 12:01 AM
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

user

01/21/2021, 12:02 AM
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

user

01/21/2021, 12:07 AM
@charles I agree we should be putting it in the title, but right now it’s in the locale not the title, right?
u

user

01/21/2021, 12:27 AM
Nope. We do not use locales anywhere except postgres and it is sort of legacy which we can remove.
u

user

01/21/2021, 12:27 AM
oh ok
3 Views
Powered by