5 ms·

I'm not evaluating what's being proposed here. In this thread anyway, I'm responding to this comment, which I regard as untrue: > They could write some pretty

I'm not evaluating what's being proposed here. In this thread anyway, I'm responding to this comment, which I regard as untrue: > They could write some pretty rough queries that could make guaranteeing QoS difficult or impossible. However, were I to evaluate what's being proposed I would say it's predicated on a matter of judgement rather than a matter of fact: you may not feel you need "all the power of SQL", you may feel that the proposal is "orders of magnitude simpler", and you may feel that things like "row level security are tricky to get right", and that's fine, but others are not obliged to share your feelings. I'm sorry, but I don't. I just don't believe that using the security engineering affordances offered by modern databases is difficult to do, no matter how many times you tell me I should believe that.

sausagefeet 3y ago
But several things are a matter of fact. > you may not feel you need "all the power of SQL" It's specified in the blog post. It does depend on the specific use case you have. In my case, I am implementing a language that is more user friendly for users to work with than SQL but compiles down to it, so in my case giving them straight SQL access would not fit the feature requirements. But, of course, it depends. > you may feel that the proposal is "orders of magnitude simpler" We can debate if it's literal "orders of magnitude" but I have a hard time seeing how for any complicated database, correctly implementing, testing, and guaranteeing future correctness, of handing access to the database out to users is less complicated than compiling some SQL. For my usecase, we have a multi-tenant database with sensitive information in it that would be bad if somehow another user was able to access it. The solution of compiling to SQL I have implemented in around 200 lines of code plus another 200 (and growing) of tests. I am making a concrete statement here: that 200 lines of code is a lot simpler than whatever you will have to do for security engineering. That does not mean what you're proposing is not the right choice given whatever constraints you have, but tell me how it is simpler.
- dventimi 3y ago
  > I'm implementing a language that is more user friendly for users to work with than SQL "User-friendly" is a matter of judgement not of fact. > I am making a concrete statement here: that 200 lines of code is a lot simpler than whatever you will have to do for security engineering Again, that's not a statement of fact, but setting that aside personally I'm unimpressed. It's easy to imagine multinenant databases with sensitive information providing safety guarantees in under 200 lines of DDL.
  - sausagefeet 3y ago
    I don't even really know what we're disagreeing about at this point. My statement from the beginning has been that handing out direct SQL access to users is not a universal solution. It can work in some cases but there are definitely cases where it is not a valid solution to the problem at hand. I happen to believe that in a realistic production database your solution is going to be significantly more complicated. I have presented a crude measurement for the complexity of my solution, and your response has just been "well, I could imagine it's just as small doing it my way". Ok, I can imagine a lot of things, too. I feel that your responses have been scoped at just trying to invalidate my most recent response rather than discussing the system as a whole and the pros and cons of various solutions, and that makes me feel frustrated.
    - dventimi 3y ago
      I'm sorry you're frustrated. I admit that I am scoping my responses to your most recent response rather than trying to discuss the system as a whole. In my experience, that's common in threaded comment systems. Whatever its shortcomings, it does help combat non-sequiturs. If you'd rather discuss the system as a whole, we can do that. As for what we're disagreeing about, maybe this will help. In this thread I have tried to say the following: 1. I believe that using a SQL role with the correct access rights, augmented by other features within modern databases, is a good option. It's not the ONLY good option, but it's not the case that it's never a good option. 2. I believe that it's not NECESSARILY true that a user could write some pretty rough queries that threaten QoS against a SQL API. There ARE steps that can be taken, right within the database. 3. I believe that exposing a SQL database to users is not NECESSARILY handing out a big surface area. Modern databases offer tools to limit the size of that surface area. They may not limit it in all possible ways to satisfy every possible person (e.g. I'm not aware of any SQL database that allows you to forbid joins, for example), but it's a mistake to believe that you can't limit the surface area AT ALL. 4. I believe that using these features (RBAC, RLS, data types, constraints, triggers, views, quotas, etc.) in development is not NECESSARILY more costly than writing something that translates a small DSL to SQL. 5. I believe it's difficult to quantify this cost or effort but in any case it's not orders-of-magnitude more difficult to use the database than to compile a DSL. 6. I believe it's presumptuous to declare that other people don't need all the power of SQL. Some people may not need it or want it, and that's fine, but if other people say that they do need it or want it, I'm not going to tell them they're wrong. 7. I believe NEITHER of us is in a position to tell other people that they're doing it wrong, or that what they're doing isn't valid, on matters of judgment. If you like compiling a DSL and it's good for you, I'm not going to say that's not valid. I'd appreciate it if you'd do likewise when I say that I like using the database because it's good for me. 8. I believe BOTH of us, however, are free to say that something is incorrect on matters of fact (e.g. numbers 1 - 4 above). If you don't disagree with any of these things then perhaps we're not disagreeing about anything after all.

sausagefeet 3y ago

But several things are a matter of fact. > you may not feel you need "all the power of SQL" It's specified in the blog post. It does depend on the specific use case you have. In my case, I am implementing a language that is more user friendly for users to work with than SQL but compiles down to it, so in my case giving them straight SQL access would not fit the feature requirements. But, of course, it depends. > you may feel that the proposal is "orders of magnitude simpler" We can debate if it's literal "orders of magnitude" but I have a hard time seeing how for any complicated database, correctly implementing, testing, and guaranteeing future correctness, of handing access to the database out to users is less complicated than compiling some SQL. For my usecase, we have a multi-tenant database with sensitive information in it that would be bad if somehow another user was able to access it. The solution of compiling to SQL I have implemented in around 200 lines of code plus another 200 (and growing) of tests. I am making a concrete statement here: that 200 lines of code is a lot simpler than whatever you will have to do for security engineering. That does not mean what you're proposing is not the right choice given whatever constraints you have, but tell me how it is simpler.

dventimi 3y ago
> I'm implementing a language that is more user friendly for users to work with than SQL "User-friendly" is a matter of judgement not of fact. > I am making a concrete statement here: that 200 lines of code is a lot simpler than whatever you will have to do for security engineering Again, that's not a statement of fact, but setting that aside personally I'm unimpressed. It's easy to imagine multinenant databases with sensitive information providing safety guarantees in under 200 lines of DDL.
- sausagefeet 3y ago
  I don't even really know what we're disagreeing about at this point. My statement from the beginning has been that handing out direct SQL access to users is not a universal solution. It can work in some cases but there are definitely cases where it is not a valid solution to the problem at hand. I happen to believe that in a realistic production database your solution is going to be significantly more complicated. I have presented a crude measurement for the complexity of my solution, and your response has just been "well, I could imagine it's just as small doing it my way". Ok, I can imagine a lot of things, too. I feel that your responses have been scoped at just trying to invalidate my most recent response rather than discussing the system as a whole and the pros and cons of various solutions, and that makes me feel frustrated.
  - dventimi 3y ago
    I'm sorry you're frustrated. I admit that I am scoping my responses to your most recent response rather than trying to discuss the system as a whole. In my experience, that's common in threaded comment systems. Whatever its shortcomings, it does help combat non-sequiturs. If you'd rather discuss the system as a whole, we can do that. As for what we're disagreeing about, maybe this will help. In this thread I have tried to say the following: 1. I believe that using a SQL role with the correct access rights, augmented by other features within modern databases, is a good option. It's not the ONLY good option, but it's not the case that it's never a good option. 2. I believe that it's not NECESSARILY true that a user could write some pretty rough queries that threaten QoS against a SQL API. There ARE steps that can be taken, right within the database. 3. I believe that exposing a SQL database to users is not NECESSARILY handing out a big surface area. Modern databases offer tools to limit the size of that surface area. They may not limit it in all possible ways to satisfy every possible person (e.g. I'm not aware of any SQL database that allows you to forbid joins, for example), but it's a mistake to believe that you can't limit the surface area AT ALL. 4. I believe that using these features (RBAC, RLS, data types, constraints, triggers, views, quotas, etc.) in development is not NECESSARILY more costly than writing something that translates a small DSL to SQL. 5. I believe it's difficult to quantify this cost or effort but in any case it's not orders-of-magnitude more difficult to use the database than to compile a DSL. 6. I believe it's presumptuous to declare that other people don't need all the power of SQL. Some people may not need it or want it, and that's fine, but if other people say that they do need it or want it, I'm not going to tell them they're wrong. 7. I believe NEITHER of us is in a position to tell other people that they're doing it wrong, or that what they're doing isn't valid, on matters of judgment. If you like compiling a DSL and it's good for you, I'm not going to say that's not valid. I'd appreciate it if you'd do likewise when I say that I like using the database because it's good for me. 8. I believe BOTH of us, however, are free to say that something is incorrect on matters of fact (e.g. numbers 1 - 4 above). If you don't disagree with any of these things then perhaps we're not disagreeing about anything after all.