Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix typos again #611

Merged
merged 1 commit into from
May 24, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion lib/ecto/adapters/sql.ex
Original file line number Diff line number Diff line change
Expand Up @@ -411,7 +411,7 @@ defmodule Ecto.Adapters.SQL do
shared Repo options such as `:timeout`. Non built-in adapters may have specific behaviour and you should
consult their documentation for more details.

For version compatiblity, please check your database's documentation:
For version compatibility, please check your database's documentation:

* _Postgrex_: [PostgreSQL doc](https://www.postgresql.org/docs/current/sql-explain.html).
* _MyXQL_: [MySQL doc](https://dev.mysql.com/doc/refman/8.0/en/explain.html).
Expand Down
2 changes: 1 addition & 1 deletion lib/ecto/adapters/sql/sandbox.ex
Original file line number Diff line number Diff line change
Expand Up @@ -224,7 +224,7 @@ defmodule Ecto.Adapters.SQL.Sandbox do
# assertions
end

By using `start_supervised!/1`, ExUnit guarantess the process finishes
By using `start_supervised!/1`, ExUnit guarantees the process finishes
before your test (the connection owner).

In some situations, however, the dynamic processes are directly started
Expand Down
2 changes: 1 addition & 1 deletion lib/ecto/migration.ex
Original file line number Diff line number Diff line change
Expand Up @@ -822,7 +822,7 @@ defmodule Ecto.Migration do

If the database adapter supports several migration lock strategies, such as
Postgrex, then review those strategies and consider using a strategy that
utilizes advisory locks to faciliate running migrations one at a time even
utilizes advisory locks to facilitate running migrations one at a time even
across multiple nodes. For example:

### Config file (PostgreSQL)
Expand Down
2 changes: 1 addition & 1 deletion test/ecto/adapters/postgres_test.exs
Original file line number Diff line number Diff line change
Expand Up @@ -829,7 +829,7 @@
query = "schema" |> where(foo: "abc") |> select([], true) |> plan()
assert all(query) == ~s{SELECT TRUE FROM "schema" AS s0 WHERE (s0."foo" = 'abc')}

query = "schema" |> where(foo: <<0, ?a, ?b, ?c>>) |> select([], true) |> plan()

Check warning on line 832 in test/ecto/adapters/postgres_test.exs

View workflow job for this annotation

GitHub Actions / unittest (1.15.6, 24.3.4.13)

this check/guard will always yield the same result

Check warning on line 832 in test/ecto/adapters/postgres_test.exs

View workflow job for this annotation

GitHub Actions / unittest (1.15.6, 26.1.2, lint)

this check/guard will always yield the same result

assert all(query) ==
~s{SELECT TRUE FROM "schema" AS s0 WHERE (s0."foo" = '\\x00616263'::bytea)}
Expand Down Expand Up @@ -1442,7 +1442,7 @@
~s{SELECT s0."x" FROM "schema" AS s0 WINDOW "w" AS (PARTITION BY s0."x", s0."z" ORDER BY s0."x")}
end

test "partition by ond order by over" do
test "partition by one order by over" do
query =
Schema
|> select([r], count(r.x) |> over(partition_by: [r.x, r.z], order_by: r.x))
Expand Down
Loading