7 ms·

> All they had to do was implement a nested set pattern for their groups The nested set pattern was considered at the time we added support for nested groups,

> All they had to do was implement a nested set pattern for their groups The nested set pattern was considered at the time we added support for nested groups, or improved it with CTEs (not sure which one of the two it was). The biggest drawback of nested sets is that adding sub groups can now become expensive. The storage needs are also far from ideal. Using PostgreSQL CTEs allowed us to work around all of this, at the cost of not supporting MySQL. This seems like a fairly reasonable trade-off, but I might be biased as I implemented it [1]. > A hack? Their DB creation schema specified a TEXT column when it should > have been a LONGTEXT column. Using LONGTEXT is not a hack, it's a choice > when your data is more than 65535 characters, and they made the wrong > choice out of ignorance. It's not ignorance, it's MySQL coming up with bizarre limits for the "TEXT" type. In MySQL, the limit for TEXT is 64 KB. In PostgreSQL, IIRC it is 1 GB. Looking back there may have been better decisions, but it's always easy to judge in hindsight. More importantly, moving away from MySQL allows us to stop worrying about this at all. > Alternatively, since this is filepaths and filenames, they could have used > a nested set pattern again and gotten 255 characters for each component of > the path and a lot more feature options for their search system! At the cost of requiring more storage space, and writes taking (potentially) much longer. You may want to mention that, instead of acting as if nested sets are a silver bullet. > This is true, but is it really a show stopper? Yes. > Wrong schema specifications and not knowing to implement nested set > patterns is a sign that they don't have a knowledgeable DBA on staff. You may want to do some more research before going down the path of suggesting GitLab employees lack knowledge. For the last two years or so we've had various engineers with excellent database knowledge working on GitLab, myself included (though I don't consider myself a PostgreSQL expert). Some of the weirder decisions were made before the right people were hired, and often these decisions are difficult to improve upon. Sometimes removing support for something is a much more efficient way of spending your time. Removing MySQL support in GitLab is one such case. [1]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10885 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10885

MrStonedOne 7y ago
>> This is true, but is it really a show stopper? >Yes. No, its not. Not everybody has to run gitlab in the same production environment that gitlab.com does. it is 100% not a show stopper. Please stop being fictitious. I could pop the last mysql gitlab version on my ARM rock64 single board computer and get by running it as a 300 page views a month internal git server for personal projects. It will work fine, with or without partial indexes. So. Again. It is 100% not a show stopper. Stop fucking lying. These technical issues are not why you want to drop mysql
- deleted 7y ago
  [deleted]
- derefr 7y ago
  They have to engineer their software for the highest-scale cases it’s going to be put to by people running it in a particular configuration. Just because Gitlab works without partial indexes for you doesn’t mean that Gitlab works without partial indexes for everyone, and software that doesn’t work for the 1% of users who use it most heavily (and probably pay GitLab the most money in support contracts) is also known as “software that doesn’t work.”
  - MrStonedOne 7y ago
    "Mysql can not scale to higher usage and is not supported for those workloads" Nobody supports mysql for scaling workloads. they support mysql purely to make it easier for their smaller users to setup and manage instances.
    - deleted 7y ago
      [deleted]
    - detaro 7y ago
      Is that relevant outside of software that can run on random shared hosting? There being able to use MySQL is a large factor, but GitLab isn't in that category.
    - tracker1 7y ago
      I don't think mySQL/MariaDB is particularly easier than PostgreSQL to setup for someone less familiar with them. Every single time I've used mySQL, I come across some odd quirk from historical context. Limiting TEXT and creating LONGTEXT instead of increasing the bounds for TEXT. Keeping utf8 as some wierd non-final version of utf that isn't a spec, instead of aliasing it to the actual utf8 spec version in new configurations. Not sure if this is still an issue, not being able to create foreign key relationships with ansi-quoted table names (backticks only here). "BINARY" fields being collated as case invariant by default (led to some really bad bugs on a primary key field). I can't think of a single time I've used mysql and didn't get odd behavior. I can't think of a single time I've used PostgreSQL, or even MS-SQL that I did. Oracle and DB2 have had some oddities as well, but at least consistent, unlike mysql.

MrStonedOne 7y ago

>> This is true, but is it really a show stopper? >Yes. No, its not. Not everybody has to run gitlab in the same production environment that gitlab.com does. it is 100% not a show stopper. Please stop being fictitious. I could pop the last mysql gitlab version on my ARM rock64 single board computer and get by running it as a 300 page views a month internal git server for personal projects. It will work fine, with or without partial indexes. So. Again. It is 100% not a show stopper. Stop fucking lying. These technical issues are not why you want to drop mysql

deleted 7y ago
[deleted]
derefr 7y ago
They have to engineer their software for the highest-scale cases it’s going to be put to by people running it in a particular configuration. Just because Gitlab works without partial indexes for you doesn’t mean that Gitlab works without partial indexes for everyone, and software that doesn’t work for the 1% of users who use it most heavily (and probably pay GitLab the most money in support contracts) is also known as “software that doesn’t work.”
- MrStonedOne 7y ago
  "Mysql can not scale to higher usage and is not supported for those workloads" Nobody supports mysql for scaling workloads. they support mysql purely to make it easier for their smaller users to setup and manage instances.
  - deleted 7y ago
    [deleted]
  - detaro 7y ago
    Is that relevant outside of software that can run on random shared hosting? There being able to use MySQL is a large factor, but GitLab isn't in that category.
  - tracker1 7y ago
    I don't think mySQL/MariaDB is particularly easier than PostgreSQL to setup for someone less familiar with them. Every single time I've used mySQL, I come across some odd quirk from historical context. Limiting TEXT and creating LONGTEXT instead of increasing the bounds for TEXT. Keeping utf8 as some wierd non-final version of utf that isn't a spec, instead of aliasing it to the actual utf8 spec version in new configurations. Not sure if this is still an issue, not being able to create foreign key relationships with ansi-quoted table names (backticks only here). "BINARY" fields being collated as case invariant by default (led to some really bad bugs on a primary key field). I can't think of a single time I've used mysql and didn't get odd behavior. I can't think of a single time I've used PostgreSQL, or even MS-SQL that I did. Oracle and DB2 have had some oddities as well, but at least consistent, unlike mysql.