- 20 2月, 2016 1 次提交
-
-
- 10 2月, 2016 2 次提交
-
-
由 Rémy Coutable 提交于
-
由 Rémy Coutable 提交于
Also: - Get rid of legacy :strict_mode - Get rid of custom :email validator - Add some shared examples to spec emails validation
-
- 02 2月, 2016 2 次提交
-
-
-
由 Stan Hu 提交于
Currently any spam detected by Akismet by non-members via API will be logged in a separate table in the admin page. Closes #5612
-
- 23 1月, 2016 1 次提交
-
-
由 Rubén Dávila 提交于
-
- 21 1月, 2016 1 次提交
-
-
由 Rubén Dávila 提交于
-
- 19 1月, 2016 1 次提交
-
-
由 Douwe Maan 提交于
-
- 14 1月, 2016 1 次提交
-
-
由 Gabriel Mazetto 提交于
-
- 09 1月, 2016 2 次提交
-
-
由 Gabriel Mazetto 提交于
-
由 Gabriel Mazetto 提交于
-
- 06 1月, 2016 1 次提交
-
-
由 Stan Hu 提交于
-
- 03 1月, 2016 1 次提交
-
-
由 Robert Speicher 提交于
Closes #201 - two-year-old bug, woo!
💥 🎉
-
- 15 12月, 2015 2 次提交
-
-
由 Gabriel Mazetto 提交于
-
由 Drew Blessing 提交于
-
- 12 12月, 2015 2 次提交
-
-
由 Kamil Trzcinski 提交于
-
由 Kamil Trzcinski 提交于
-
- 11 12月, 2015 1 次提交
-
-
由 Grzegorz Bizon 提交于
This adds a ability to use multiple different authentication token fields in other models. From now on it is necessary to add authentication token field manually in each class that implements this mixin.
-
- 09 12月, 2015 1 次提交
-
-
由 Stan Hu 提交于
-
- 08 12月, 2015 1 次提交
-
-
由 Robert Speicher 提交于
-
- 03 12月, 2015 1 次提交
-
-
由 Valery Sizov 提交于
-
- 02 12月, 2015 1 次提交
-
-
由 Valery Sizov 提交于
-
- 19 11月, 2015 1 次提交
-
-
由 Yorick Peterse 提交于
-
- 18 11月, 2015 7 次提交
-
-
由 Yorick Peterse 提交于
This won't work efficiently if you happen to have a lot of projects.
-
由 Yorick Peterse 提交于
These changes are based on those from commit 03f5ff75, except they use a UNION instead of plucking IDs into memory.
-
由 Yorick Peterse 提交于
These methods no longer include public groups/projects (that don't belong to the actual user) as this is handled by the various finder classes now. This also removes the need for passing extra arguments. Note that memoizing was removed _explicitly_. For whatever reason doing so messes up the users controller to a point where it claims a certain user does _not_ have access to certain groups/projects when it does have access. Existing code shouldn't be affected as these methods are only called in ways that they'd run queries anyway (e.g. a combination of "any?" and "each" which would run 2 queries regardless of memoizing).
-
由 Yorick Peterse 提交于
This new setup no longer loads any IDs into memory using "pluck", instead using SQL UNIONs to merge the various datasets together. This results in greatly improved query performance as well as a reduction of memory usage. The old setup was in particular problematic when requesting the authorized projects _including_ public/internal projects as this would result in roughly 65000 project IDs being loaded into memory. These IDs would in turn be passed to other queries.
-
由 Yorick Peterse 提交于
-
由 Yorick Peterse 提交于
This removes the need for plucking any IDs into Ruby.
-
由 Yorick Peterse 提交于
This allows retrieving of the list of authorized projects using a single query, without having to load any IDs into Ruby. This in turn also means we can remove the method User#authorized_projects_id.
-
- 16 11月, 2015 1 次提交
-
-
由 Kamil Trzcinski 提交于
-
- 14 11月, 2015 1 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 30 10月, 2015 4 次提交
-
-
由 Yorick Peterse 提交于
This further improves performance of User.find_by_any_email and is roughly twice as fast as the previous UNION setup. Thanks again to @dlemstra for suggesting this.
-
由 Yorick Peterse 提交于
MySQL doesn't support the previous syntax.
-
由 Yorick Peterse 提交于
This is significantly faster than using a sub-query, at least when run on the GitLab.com production database. The benchmarks are a lot slower now with these changes, most likely due to PostgreSQL choosing a different (and less efficient) plan based on the amount of data present in the test database. Thanks to @dlemstra for suggesting the use of a UNION.
-
由 Yorick Peterse 提交于
This query used to rely on a JOIN, effectively producing the following SQL: SELECT users.* FROM users LEFT OUTER JOIN emails ON emails.user_id = users.id WHERE (users.email = X OR emails.email = X) LIMIT 1; The use of a JOIN means having to scan over all Emails and users, join them together and then filter out the rows that don't match the criteria (though this step may be taken into account already when joining). In the new setup this query instead uses a sub-query, producing the following SQL: SELECT * FROM users WHERE id IN (select user_id FROM emails WHERE email = X) OR email = X LIMIT 1; This query has the benefit that it: 1. Doesn't have to JOIN any rows 2. Only has to operate on a relatively small set of rows from the "emails" table. Since most users will only have a handful of Emails associated (certainly not hundreds or even thousands) the size of the set returned by the sub-query is small enough that it should not become problematic. Performance of the old versus new version can be measured using the following benchmark: # Save this in ./bench.rb require 'benchmark/ips' email = 'yorick@gitlab.com' def User.find_by_any_email_old(email) user_table = arel_table email_table = Email.arel_table query = user_table. project(user_table[Arel.star]). join(email_table, Arel::Nodes::OuterJoin). on(user_table[:id].eq(email_table[:user_id])). where(user_table[:email].eq(email).or(email_table[:email].eq(email))) find_by_sql(query.to_sql).first end Benchmark.ips do |bench| bench.report 'original' do User.find_by_any_email_old(email) end bench.report 'optimized' do User.find_by_any_email(email) end bench.compare! end Running this locally using "bundle exec rails r bench.rb" produces the following output: Calculating ------------------------------------- original 1.000 i/100ms optimized 93.000 i/100ms ------------------------------------------------- original 11.103 (± 0.0%) i/s - 56.000 optimized 948.713 (± 5.3%) i/s - 4.743k Comparison: optimized: 948.7 i/s original: 11.1 i/s - 85.45x slower In other words, the new setup is 85x faster compared to the old setup, at least when running this benchmark locally. For GitLab.com these improvements result in User.find_by_any_email taking only ~170 ms to run, instead of around 800 ms. While this is "only" an improvement of about 4.5 times (instead of 85x) it's still significantly better than before. Fixes #3242
-
- 26 10月, 2015 1 次提交
-
-
由 Kamil Trzcinski 提交于
-
- 17 10月, 2015 1 次提交
-
-
由 Stan Hu 提交于
The counter_cache decrement function is called when a project star is deleted, but there was no guarantee multiple workers would not attempt to delete the same item simultaneously. Use an atomic update to prevent the count from going negative. Closes #3067
-
- 15 10月, 2015 1 次提交
-
-
由 Yorick Peterse 提交于
Performance is improved in two steps: 1. On PostgreSQL an expression index is used for checking lower(email) and lower(username). 2. The check to determine if we're searching for a username or Email is moved to Ruby. Thanks to @haynes for suggesting and writing the initial implementation of this. Moving the check to Ruby makes this method an additional 1.5 times faster compared to doing the check in the SQL query. With performance being improved I've now also tweaked the amount of iterations required by the User.by_login benchmark. This method now runs between 900 and 1000 iterations per second.
-
- 06 10月, 2015 1 次提交
-
-
由 Peter Göbel 提交于
-