Fix typos (#31)

Found via:
- `codespell -S target -L crate,spected,childrens`
- `typos --format brief`

Author: kianmeng

CONTRIBUTING.md

@@ -87,7 +87,7 @@ Once it's filed:
 
 ### Suggesting Enhancements
 
-If you want to suggest an enhacement or new feature for the project, please [open a new issue](/issues) describing what you desire to improve, and, potentially, how you plan to contribute to the project.
+If you want to suggest an enhancement or new feature for the project, please [open a new issue](/issues) describing what you desire to improve, and, potentially, how you plan to contribute to the project.
 
 #### Before Submitting an Enhancement
 

README.md

@@ -29,7 +29,7 @@ You can read it [by clicking this link](https://zerodaycode.github.io/canyon-boo
 a `PostgreSQL` database and an `SqlServer` one in the same project.
 - Is macro based. With a few annotations and a configuration file, you are ready to write your data access.
 - Allows **migrations**. `Canyon-SQL` comes with a *god-mode* that will manage every table on your database for you. You can modify in `Canyon` code your tables internally, altering columns, setting up constraints...
-Also, in the future, we have plans to allow you to manipulate the whole server, like creating databases, altering configurations... everything, but in a programatically approach with `Canyon`!
+Also, in the future, we have plans to allow you to manipulate the whole server, like creating databases, altering configurations... everything, but in a programmatically approach with `Canyon`!
 
 ## Supported databases
 
@@ -81,7 +81,7 @@ Note the leading reference on the `find_by_pk(...)` parameter. This associated f
 ### Building more complex queries
 
 For exemplify the capabilities of `Canyon`, we will use `SelectQueryBuilder<T>`, which implements the `QueryBuilder<T>` trait
-for build a more complex whery, filteing data and joining tables.
+for build a more complex where, filteing data and joining tables.
 
 ```rust
 let mut select_with_joins = LeagueTournament::select_query();
@@ -101,12 +101,12 @@ let mut select_with_joins = LeagueTournament::select_query();
 ```
 
 > Note: For now, when you use joins, you will need to create a new model with the columns in both tables (in case that you desire the data in such columns), but just follows the habitual process with the CanyonMapper.
-It will try to retrieve the data for every field declared. If you don't declare a field that is in the open clause, in this case (*), that field wont be retrieved. No problem. But if you have fields that aren't mapp
+It will try to retrieve the data for every field declared. If you don't declare a field that is in the open clause, in this case (*), that field won't be retrieved. No problem. But if you have fields that aren't map
 able with some column in the database, the program will panic.
 
 ## More examples
 
-If you want to see more examples, you can take a look into the `tests` folder, at the root of this repository. Every avaliable database operation is tested there, so you can use it to find the usage of the described operations in the documentation metioned above
+If you want to see more examples, you can take a look into the `tests` folder, at the root of this repository. Every available database operation is tested there, so you can use it to find the usage of the described operations in the documentation mentioned above
 
 ## Contributing to CANYON-SQL
 
@@ -115,7 +115,7 @@ You can take a look to our [templated guide]((./CONTRIBUTING.md)).
 
 But, to summarize:
 
-- Take a look at the already opened issues, to see if already exists of it's someone already taking care about solving it. Even tho, you can enter to participate and explain your point of view, or even help to acomplish the task
+- Take a look at the already opened issues, to see if already exists of it's someone already taking care about solving it. Even tho, you can enter to participate and explain your point of view, or even help to accomplish the task
 - Make a fork of `Canyon-SQL`
 - If you opened an issue, create a branch from the base branch of the repo (that's the default), and point it to your fork
 - After complete your changes, open a `PR` to the default branch. Fill the template provided in the best way you're able to do it

canyon_connection/src/canyon_database_connector.rs

@@ -61,7 +61,7 @@ impl DatabaseConnection {
 
                 tokio::spawn(async move {
                     if let Err(e) = new_connection.await {
-                        eprintln!("An error occured while trying to connect to the PostgreSQL database: {e}");
+                        eprintln!("An error occurred while trying to connect to the PostgreSQL database: {e}");
                     }
                 });
 
@@ -96,7 +96,7 @@ impl DatabaseConnection {
                 // TcpStream to connect to the server.
                 let tcp = TcpStream::connect(config.get_addr())
                     .await
-                    .expect("Error instanciating the SqlServer TCP Stream");
+                    .expect("Error instantiating the SqlServer TCP Stream");
 
                 // We'll disable the Nagle algorithm. Buffering is handled
                 // internally with a `Sink`.

canyon_connection/src/lib.rs

@@ -40,7 +40,7 @@ lazy_static! {
 /// in the configuration file.
 ///
 /// This avoids Canyon to create a new connection to the database on every query, potentially avoiding bottlenecks
-/// derivated from the instanciation of that new conn every time.
+/// derivated from the instantiation of that new conn every time.
 ///
 /// Note: We noticed with the integration tests that the [`tokio_postgres`] crate (PostgreSQL) is able to work in an async environment
 /// with a new connection per query without no problem, but the [`tiberius`] crate (MSSQL) sufferes a lot when it has continuous

canyon_crud/src/bounds.rs

@@ -45,7 +45,7 @@ where
 /// and convert it to a tuple struct formed by the column name as an String,
 /// and the dynamic value of the [`QueryParameter<'_>`] trait object contained
 /// inside the variant requested,
-/// enabling a convertion of that value into something
+/// enabling a conversion of that value into something
 /// that can be part of an SQL query.
 ///
 ///
@@ -229,7 +229,7 @@ pub trait QueryParameter<'a>: std::fmt::Debug + Sync + Send {
 /// This implementation is necessary because of the generic amplitude
 /// of the arguments of the [`Transaction::query`], that should work with
 /// a collection of [`QueryParameter<'a>`], in order to allow a workflow
-/// that is not dependant of the specific type of the argument that holds
+/// that is not dependent of the specific type of the argument that holds
 /// the query parameters of the database connectors
 impl<'a> IntoSql<'a> for &'a dyn QueryParameter<'a> {
     fn into_sql(self) -> ColumnData<'a> {

canyon_crud/src/crud.rs

@@ -210,7 +210,7 @@ mod sqlserver_query_launcher {
     where
         Z: AsRef<[&'a dyn QueryParameter<'a>]> + Sync + Send + 'a,
     {
-        // Re-generate de insert statement to adecuate it to the SQL SERVER syntax to retrieve the PK value(s) after insert
+        // Re-generate de insert statement to adequate it to the SQL SERVER syntax to retrieve the PK value(s) after insert
         if stmt.contains("RETURNING") {
             let c = stmt.clone();
             let temp = c

canyon_crud/src/query_elements/operators.rs

@@ -9,9 +9,9 @@ pub enum Comp {
     Eq,
     /// Operator "!=" not equals
     Neq,
-    /// Operator ">" greather than value
+    /// Operator ">" greater than value
     Gt,
-    /// Operator ">=" greather or equals than value
+    /// Operator ">=" greater or equals than value
     GtEq,
     /// Operator "<" less than value
     Lt,

canyon_crud/src/query_elements/query_builder.rs

@@ -337,7 +337,7 @@ where
     /// * `col1` - The left side of the ON operator for the join
     /// * `col2` - The right side of the ON operator for the join
     ///
-    /// > Note: The order on the column paramenters is irrelevant
+    /// > Note: The order on the column parameters is irrelevant
     pub fn left_join(&mut self, join_table: &str, col1: &str, col2: &str) -> &mut Self {
         self._inner
             .query
@@ -353,7 +353,7 @@ where
     /// * `col1` - The left side of the ON operator for the join
     /// * `col2` - The right side of the ON operator for the join
     ///
-    /// > Note: The order on the column paramenters is irrelevant
+    /// > Note: The order on the column parameters is irrelevant
     pub fn inner_join(&mut self, join_table: &str, col1: &str, col2: &str) -> &mut Self {
         self._inner
             .query
@@ -369,7 +369,7 @@ where
     /// * `col1` - The left side of the ON operator for the join
     /// * `col2` - The right side of the ON operator for the join
     ///
-    /// > Note: The order on the column paramenters is irrelevant
+    /// > Note: The order on the column parameters is irrelevant
     pub fn right_join(&mut self, join_table: &str, col1: &str, col2: &str) -> &mut Self {
         self._inner
             .query
@@ -385,7 +385,7 @@ where
     /// * `col1` - The left side of the ON operator for the join
     /// * `col2` - The right side of the ON operator for the join
     ///
-    /// > Note: The order on the column paramenters is irrelevant
+    /// > Note: The order on the column parameters is irrelevant
     pub fn full_join(&mut self, join_table: &str, col1: &str, col2: &str) -> &mut Self {
         self._inner
             .query
@@ -511,7 +511,7 @@ where
             )
         }
 
-        let cap = columns.len() * 50; // Reserving an enought initial capacity per set clause
+        let cap = columns.len() * 50; // Reserving an enough initial capacity per set clause
         let mut set_clause = String::with_capacity(cap);
         set_clause.push_str(" SET ");
 

canyon_crud/src/result.rs

@@ -33,7 +33,7 @@ impl<T> DatabaseResult<T> {
     }
 
     /// Returns a [`Vec<T>`] filled with instances of the type T.
-    /// Z param it's used to constrait the types that can call this method.
+    /// Z param it's used to constraint the types that can call this method.
     ///
     /// Also, provides a way to statically call `Z::deserialize_<db>` method,
     /// which it's the implementation used by the macros to automatically

canyon_macros/src/lib.rs

@@ -279,7 +279,7 @@ pub fn canyon_entity(
     // Fill the register with the data of the attached struct
     CANYON_REGISTER_ENTITIES
         .lock()
-        .expect("Error adquiring Mutex guard on Canyon Entity macro")
+        .expect("Error acquiring Mutex guard on Canyon Entity macro")
         .push(new_entity);
 
     // Assemble everything
@@ -307,7 +307,7 @@ pub fn crud_operations(input: proc_macro::TokenStream) -> proc_macro::TokenStrea
     // Construct a representation of Rust code as a syntax tree
     // that we can manipulate
 
-    // Calls the helper struct to build the tokens that generates the final CRUD methos
+    // Calls the helper struct to build the tokens that generates the final CRUD methods
     let ast: DeriveInput =
         syn::parse(input).expect("Error parsing `Canyon Entity for generate the CRUD methods");
     let macro_data = MacroTokens::new(&ast);
@@ -366,7 +366,7 @@ fn impl_crud_operations_trait_for_struct(
     let fk_method_signatures = _search_by_fk_tokens.iter().map(|(sign, _)| sign);
     let fk_method_implementations = _search_by_fk_tokens.iter().map(|(_, m_impl)| m_impl);
 
-    // The tokens for generating the methods that enable Canyon to retrive the child entities that are of T type
+    // The tokens for generating the methods that enable Canyon to retrieve the child entities that are of T type
     // given a parent entity U: ForeignKeyable, as an associated function for the child type (T)
     let _search_by_revese_fk_tokens: Vec<(TokenStream, TokenStream)> =
         generate_find_by_reverse_foreign_key_tokens(macro_data, &table_schema_data);
@@ -426,7 +426,7 @@ fn impl_crud_operations_trait_for_struct(
 
             /// Hidden trait for generate the foreign key operations available
             /// in Canyon without have to define them before hand in CrudOperations
-            /// because it's just imposible with the actual system (where the methods
+            /// because it's just impossible with the actual system (where the methods
             /// are generated dynamically based on some properties of the `foreign_key`
             /// annotation)
             #[canyon_sql::macros::async_trait]