Skip to content

March 2022 meeting notes

Asynchronous discussions

2022-03-25

State of Mathesar check-in

  • Added by: Kriti
  • Summary: Check in on alpha release goals and discuss progress. Also discuss hiring.
  • Participants: Brent, Dominykas, Ghislaine, Kriti, Mukesh, Pavish, Sean, Han

Notes

  • Alpha release check in
    • Milestones left:
      • Initial Data Types
      • Links Between Tables
      • Queries and Views
      • UI Styling
      • Deployment
      • Alpha Release
    • Goals for alpha release:
      • NOT production ready
      • Basic functionality that demonstrates our value proposition
      • Allow users to connect existing DBs to Mathesar
      • Build out support for designs, don’t worry about extensibility yet
      • Bugs and edge cases not being handled are okay
    • Check in:
      • How does everyone think it’s going?
        • Slower than expected, Initial Data Types are taking longer
        • Queries and Views are going to be a lot of work
        • GSoC has slowed down coding time
        • It took us a long time to get the query builder design, more interaction between product and design
          • Making the whole UX consistent based on new designs
          • This might involve a lot of frontend work, we’ll balance time
      • Concerns? Questions? Ideas?
        • Should we assume we’ll have future features when we’re building current feature? (e.g. should we assume we’ll have undo when building frontend UX)
          • Not right now
      • Feature idea: usage data collection for beta? (opt-in)
  • Upcoming hiring
    • Localization engineer
      • Requirements?
        • Frontend skills (JS + frontend framework, TypeScript)
        • Python
        • Error message localization?
        • Bilingual in English and Japanese
        • Japanese local knowledge
    • Evangelist / Community Advocate
      • Videos, documentation, community management
      • In a couple months
    • Design help
      • Contract work to help with Views and UI Styling
    • Engineers?
      • Frontend engineer, start hiring process soon
      • Need to get better at parallelizing on the backend
        • Not enough codebase for another backend engineer to make sense any time soon
    • Could contract out for public marketing website, including copy and graphic design, etc.

Data Explorer UX

  • Added by: Ghislaine
  • Summary: An overview of Data Explorer’s (visual query builder) user flow in preparation for spec review. Recommended reading before meeting: Data Explorer Spec
  • Participants: Brent, Ghislaine, Kriti, Mukesh, Pavish, Sean, Han

Ghislaine went over the wireframes and people asked questions about it and made some design suggestions. No major changes were suggested, a more detailed review will take place asynchronously on the pull request.

2022-03-07

Column Identifier Discussion

Sync call to disuss on how to move forward with conflicting changes with Brent’s work on grouping API and Mukesh’s work on Mathesar 896 Change records api parameters to use column id instead of name #1047.

  • Participants: Brent, Mukesh

Questions

  1. Will there be DDL outside of columns operation, should attnum be used outside columns operations - No
  2. DML should use column name or id?

Notes:

  • Prefer to have attnums everywhere for consistency if possible.
  • View are treated as table in postgres and view columns are stored in similar fashion, with each view column having a attnum as reference.
  • Creating auxillary hidden views without the knowledge of the users won’t be a good idea as it would interfere with user’s database and won’t be optional like custom types.
  • Suggestion to use Use autogenerated pseudo identifier for temporary aliased columns.
  • We could have a feature where the frontend could supply the alias of the column, this could solve the issue dom was talking about. But it would be a problem if only backend has information about a computed/aliased column. For example if a function generates a temporary column.

Conclusion

  • Put a pause on the making changes to the grouping response in PR.
  • Records operations should be the only DML. Answers question (1)
  • Maybe we need a directory to separate DML and DDL operations, some of the constraint operation can use a column DDL operation.
  • Add it as a topic to our weekly meeting.

2022-03-01

Display options Discussion

Sync call to discuss about display options validation especially around datetime, based on Matrix Discussion

  • Participants: Kriti, Pavish, Mukesh, Dominykas, Sean

Notes

  • Validation

    • We do generally want display options to be validated by the backend.
    • For datetime types, it doesn’t make sense to build in complete validation on the backend.
      • Formatting strings can contain arbitrary non-token information.
      • We need to make sure frontend and backend validation matches and that’s a lot of work - probably unnecessary, will probably lead to inconsistencies in the implementation.
      • The backend will only validate length to make sure random data is not stored.
      • Frontend will enforce additional rules.
      • Frontend cannot strictly rely on data from the backend

  • Format

    • Length = 255
    • Only one string for format