4 ms·

I'm sorry if this question is stupid, I'm still learning a little about technology. The little bit of knowledge I have tells me that my product team shouldn't

I'm sorry if this question is stupid, I'm still learning a little about technology. The little bit of knowledge I have tells me that my product team shouldn't directly access the same production database as my application. The idea for this product would be to create a copy of my production base and give access to it through this tool? Wouldn't the cost of this replica be too expensive?

mistersys 4y ago
In my experience in tech, most teams directly access and manipulate production frequently. Bigger companies usually have restrictions on this but in the start up world not so much.
- TeeWEE 4y ago
  That’s a big red flag if those teams are not engineering teams. Don’t you have CI CD pipelines setup with something like flyway?
pavish 4y ago
(Mathesar core team member here) My previous job was in a biggish e-commerce company and the business teams would send spreadsheets with corrections to the data (like updating descriptions, changes in pricing etc.,) almost every day, and the developers had to make those changes in production. We ended up building an inhouse application to let the product team edit production data directly, with some restrictions. One of Mathesar's goals is to solve collaboration issues like these. Mathesar allows setting up users with different access levels[1], so it's easier to create users with limited access. As part of our roadmap[2], we also intend to allow configuring permissions at a more granular level, such as row & column level access to tables. So, developers could breathe freely when providing business teams access to the underlying database. [1] https://docs.mathesar.org/product/users/ https://docs.mathesar.org/product/users/ [2] https://mathesar.org/roadmap.html https://mathesar.org/roadmap.html
TeeWEE 4y ago
You’re actually right. You don’t want people to edit the DB or schema in this manner. Schema migrations should go via CI/CD and data changes via your app. Otherwise it’s gets messy indeed.
- kgodey 4y ago
  Mathesar is designed to be used for a bunch of different types of use cases. I agree you shouldn't allow users to change the schema if you're connecting Mathesar to a production database (that would mess a lot of things up!) We've designed our user roles to account for this – you would assign "Editor" permissions to users, and they can only edit data, but not change anything related to the structure. On the other hand, if you're using Mathesar as your primary tool to work with your data, it's really nice to be able to change the schema to align with changes in your mental models or workflows.
dmos62 4y ago
To add to what Pavish said, reads are always safe, so you can examine, monitor, make reports and what we call Explorations (our user-friendly spin on Postgres views) of your data without worries. When it comes to adding data and updating it, that can be safe as well in many cases, but definitely should consult with someone that knows the specifics of your application. Schema changes, however, are very likely to break something, hence the permission system Pavish described.

mistersys 4y ago

In my experience in tech, most teams directly access and manipulate production frequently. Bigger companies usually have restrictions on this but in the start up world not so much.

TeeWEE 4y ago
That’s a big red flag if those teams are not engineering teams. Don’t you have CI CD pipelines setup with something like flyway?

pavish 4y ago

(Mathesar core team member here) My previous job was in a biggish e-commerce company and the business teams would send spreadsheets with corrections to the data (like updating descriptions, changes in pricing etc.,) almost every day, and the developers had to make those changes in production. We ended up building an inhouse application to let the product team edit production data directly, with some restrictions. One of Mathesar's goals is to solve collaboration issues like these. Mathesar allows setting up users with different access levels[1], so it's easier to create users with limited access. As part of our roadmap[2], we also intend to allow configuring permissions at a more granular level, such as row & column level access to tables. So, developers could breathe freely when providing business teams access to the underlying database. [1] https://docs.mathesar.org/product/users/ https://docs.mathesar.org/product/users/ [2] https://mathesar.org/roadmap.html https://mathesar.org/roadmap.html

TeeWEE 4y ago

You’re actually right. You don’t want people to edit the DB or schema in this manner. Schema migrations should go via CI/CD and data changes via your app. Otherwise it’s gets messy indeed.

kgodey 4y ago
Mathesar is designed to be used for a bunch of different types of use cases. I agree you shouldn't allow users to change the schema if you're connecting Mathesar to a production database (that would mess a lot of things up!) We've designed our user roles to account for this – you would assign "Editor" permissions to users, and they can only edit data, but not change anything related to the structure. On the other hand, if you're using Mathesar as your primary tool to work with your data, it's really nice to be able to change the schema to align with changes in your mental models or workflows.

dmos62 4y ago

To add to what Pavish said, reads are always safe, so you can examine, monitor, make reports and what we call Explorations (our user-friendly spin on Postgres views) of your data without worries. When it comes to adding data and updating it, that can be safe as well in many cases, but definitely should consult with someone that knows the specifics of your application. Schema changes, however, are very likely to break something, hence the permission system Pavish described.