Skip to content

2022-11-17 weekly meeting

Cycle 5 progress

  • Brent check-in
    • live demo server up
    • variable available to flag for front end
    • password is changed on demo server
  • Sean check-in
    • recent slow-down due to unexpected rabbit hole
    • Feeling good about high priority tasks
    • We’ve had more external contributors
      • quality has been better
      • paying off by taking things off internal plate
    • Things are looking really good due to design implementation
    • working on record summary (template config)
    • small things on record page
    • after that: styling
  • Ghislaine
    • Last week, had better productivity
    • Working on website
    • work is clear
    • will contribute to styling work after website
  • Anish
    • Got exploration descriptions merged
    • Working on Array filtering for live demo
  • Mukesh
    • working on users and permissions
    • DBs, Schemas in the works
    • Brent has concerns about current approach, we’ll discuss later in the meeting
  • Pavish
    • Not sure if there’s time for data import styling
    • Working on DE summarization FE changes
    • Working on live demo banner
  • Dom
    • working on summarization transform in DE
    • Now going back to clean up some things that were rushed to unblock Frontend
    • DE “styling” changes
    • Full backlog
    • Summarization should be working by 22nd
    • Styling less certain, will discuss priorities with Pavish
  • Rajat
    • Schema page is looking good
    • Table Inspector page is in review
      • A couple things for table inspector still in the queue
    • working on table page and navigation
      • aiming to be done by 22nd end of day
  • Kriti
    • Demo video
      • We have a demo script revision from production company
      • Met with prod company last week, walked them through product
    • Working on website
      • Had a design session with Ghislaine
      • Evaluating vendors
    • Working on legal agreement for providing professional services to early adopters
    • Wrote up notes on deployment (private document)
      • Will clean up notes
      • Will schedule a discussion with backend team to figure out how to implement all this
    • Sean suggested looking into getting notifications from HN for Mathesar mentions before launch, Kriti will add todo for it

Website walkthrough

  • Using Jekyll
  • Looks pretty good to this editor
  • Figma link (if you have access):

Cycle 6 planning

  • Cycle 5 ends this week
  • We’ll be doing Cycle 6 planning next week
  • Basic goal for Cycle 6: “Get Mathesar ready to share on Hacker News”
    • Complete styling
    • Deployment tasks
    • Documentation
    • Website refinement
  • We’ll have a hard deadline of Dec 23, CCI goes on winter break for the week afterwards.
  • We will launch in January.

Throw targeted error message for columns no longer present in the Query

We’re having some disagreements regarding #1905; specifically, what information we want to convey about queries whose dependency columns or tables are missing; Figma Design is showing a list of columns that are missing from the query. But Mukesh wants to show a warning(using dependency graph UI) right when a column referenced by a query is deleted instead of throwing up an error after the column is deleted. Since a dependency graph is not feasible right now, can we settle for showing up only the one deleted column at a time as it is much easier on the backend?


  • We shouldn’t spend a lot of time figuring out one error message, we have bigger priorities
  • We’ll proceed with showing one column only for now
    • Ghislaine will adjust error message in Figma design
    • We recognize this isn’t optimal UX - we would like users to have a one-click recovery option
      • Mukesh will create issue to track improving error recovery for users, we can prioritize this separately

Style duplication between django templates and svelte code

Attendees: Pavish, Sean, Rajat

Summary: We would want to use styles defined in our svelte side of the frontend, in the login page. We might also want to place the live demo banner on the django templates. This discussion is regarding the benefits of using django templates for these and overlooking the style duplication for now, or whether we should move these to svelte instead.


  • The frontend team is okay with the duplication, since it’ll be quite minimal.
  • We will continue using django templates for the login page and banner.

Users and permissions for production

  • Attendees: Brent, Kriti, Ghislaine, Mukesh, Dom (partial)

Brent has concerns about our expectations and assumptions about what we mean by “production environment”, and how far we want to go with the Django-managed permissions model


  • We’re relying on our permissions to make sure that users can’t perform DDL operations
  • Postgres permissions are much more battle-tested than the Django permissions in our product
  • We’re requiring root access to the database during setup, so the user will only depend on our code to make sure unexpected DDL operations don’t happen
    • We’re still an alpha product
    • We don’t want to lose or unexpectedly change user data
  • We should set expectations / warnings appropriately in our documentation
  • Mukesh also has concerns about our long term plan of “bundling” Postgres permissions within our user roles, but since that plan is still ill-defined and not blocking anything, we decided not to discuss it right now.


  • We’ll proceed with our current permission model
  • We’ve added the following to our first release requirements:
    • Document how to set up Mathesar with a “no DDL” user so that DDL operations are not even possible
    • We may also want to document how to set up Mathesar with a read only user
    • The frontend should disable the appropriate options when Mathesar is set up without full access to the database.
      • We’ll do some testing.

Data sets discussion

  • Attendees: Brent, Kriti, Ghislaine, Mukesh

We need to decide what data sets we’ll have in the live demo. This also affects website work since we have a “use cases” section on the website homepage.


  • Library management
    • purpose: show inventory management and managing rentals
  • “Academics” data set
    • purpose: show off Mathesar technical features (self-referential FKs)
  • Event planning data set
    • Speakers, talks, rooms, tracks
    • Make explorations for “first day speakers”, “room A schedule”, “everyone talking during time B”
  • Project management + CRM data set
    • Task: description, start date, due date, completed, assignee
    • Projects with deadlines
    • Tasks can belong to Projects
    • Exploration: non-completed tasks
  • Movie collection and rating
    • Showcase hobby related data set
  • GPT labeling use case?
    • Mukesh will make an example schema for this before we decide
  • Calorie tracking app
    • Would be useful for a large set of people
    • Would be good to have calculated columns in the future
  • No expense tracking (we don’t have calculated fields, not clear how we can demonstrate that it’s better than a spreadsheet)
    • Potentially add in the future
  • In the future, we should push that it’s a “unified” interface that combines CRM and event planning and payroll and whatnot (run your entire business database)
  • UI for data populated by script – e.g. price tracker or something
    • The purpose would be to showcase Mathesar as a UI for data in Postgres
  • Roster - grades, teachers, students, absentee
  • Disaster preparedness
    • Resources for where to get things like food etc.
    • We should do this once we have Location data type

Not sure if we should do project management since it’s so common and there are a lot of specialized software for it, Mathesar might not look good. Roster might be better


Prioritized list of data sets.

  • Library management system
  • Movie collection
    • Can base it on CC0 dataset here
    • Please don’t use JSON fields, we don’t have a good UI for them yet, convert them into relational data
  • Event planning - conference
    • Might be cute to do “MathesarCon”, talk names can reference our features
    • Kriti can help with copy if needed
  • “UI for data entered outside Mathesar” (price tracker or something similar)
    • Maybe use (make it friendly for non-technical users)
  • Calorie tracking
  • Roster data set

Even just the top 4 would be great.

Deprioritized “academics data set” since demo use cases should be based around use cases