diff --git a/docs/database/migrations.mdx b/docs/database/migrations.mdx index 2f11ec7b7..6ee5ccb03 100644 --- a/docs/database/migrations.mdx +++ b/docs/database/migrations.mdx @@ -256,7 +256,7 @@ Within both of these methods, you may use the TinyORM schema builder to expressi } // namespace Migrations -Migration classes can be named in two formats, StudlyCase without the datetime prefix and snake_case with the datetime prefix. If the StudlyCase name is used then the `T_MIGRATION` macro must also be used in the migration class. +Migration classes can be named in two formats, StudlyCase without the datetime prefix and "snake_case" with the datetime prefix. If the StudlyCase name is used then the `T_MIGRATION` macro must also be used in the migration class. Naming with the datetime prefix should look like this. diff --git a/docs/tinyorm/casts.mdx b/docs/tinyorm/casts.mdx index e74e296a3..619bc0428 100644 --- a/docs/tinyorm/casts.mdx +++ b/docs/tinyorm/casts.mdx @@ -26,7 +26,7 @@ Accessors are currently only used during the serialization by the [Appending Val ### Defining An Accessor -An accessor transforms a TinyORM attribute value when it is accessed (currently during serialization only by the [Appending Values](tinyorm/serialization.mdx#appending-values-to-json) feature). To define an accessor, create a protected method on your model to represent the accessible attribute. This method name should correspond to the "camel case" representation of the true underlying model attribute / database column when applicable. +An accessor transforms a TinyORM attribute value when it is accessed (currently during serialization only by the [Appending Values](tinyorm/serialization.mdx#appending-values-to-json) feature). To define an accessor, create a protected method on your model to represent the accessible attribute. This method name should correspond to the "camelCase" representation of the true underlying model attribute / database column when applicable. In this example, we'll define an accessor for the `first_name` attribute. The accessor will automatically be called by TinyORM during serialization if the `first_name` attribute is defined in the `u_appends` data member set. All attribute accessor methods must return the `Orm::Tiny::Casts::Attribute`: diff --git a/docs/tinyorm/getting-started.mdx b/docs/tinyorm/getting-started.mdx index 31e495148..38aeded82 100644 --- a/docs/tinyorm/getting-started.mdx +++ b/docs/tinyorm/getting-started.mdx @@ -129,7 +129,7 @@ Let's examine a basic model class and discuss some of TinyORM's key conventions: ### Table Names -After glancing at the example above, you may have noticed that we did not tell TinyORM which database table corresponds to our `Flight` model. By convention, the "snake case", plural name of the class will be used as the table name unless another name is explicitly specified. So, in this case, TinyORM will assume the `Flight` model stores records in the `flights` table, while an `AirTrafficController` model would store records in an `air_traffic_controllers` table. +After glancing at the example above, you may have noticed that we did not tell TinyORM which database table corresponds to our `Flight` model. By convention, the "snake_case", plural name of the class will be used as the table name unless another name is explicitly specified. So, in this case, TinyORM will assume the `Flight` model stores records in the `flights` table, while an `AirTrafficController` model would store records in an `air_traffic_controllers` table. If your model's corresponding database table does not fit this convention, you may manually specify the model's table name by defining the private `u_table` data member on the model: diff --git a/docs/tinyorm/relationships.mdx b/docs/tinyorm/relationships.mdx index 6f8e4b320..43d0ec5c7 100644 --- a/docs/tinyorm/relationships.mdx +++ b/docs/tinyorm/relationships.mdx @@ -203,7 +203,7 @@ If the parent model does not use `id` as its primary key, or you wish to find th return belongsTo("foreign_key", "owner_key"); } -The third `belongsTo` parameter is the relation name, if you pass it, the foreign key name will be determined from it. By convention, TinyORM will "snake case" this relation name and suffix it with a `_` followed by the name of the parent model's primary key column to generate foreign key, the `__func__` predefined identifier is ideal for this. The relation name is also used in BelongsTo's `associate` and `disassociate` methods: +The third `belongsTo` parameter is the relation name, if you pass it, the foreign key name will be determined from it. By convention, TinyORM will "snake_case" this relation name and suffix it with a `_` followed by the name of the parent model's primary key column to generate foreign key, the `__func__` predefined identifier is ideal for this. The relation name is also used in BelongsTo's `associate` and `disassociate` methods: /*! Get the user that owns the phone. */ std::unique_ptr> @@ -251,7 +251,7 @@ A one-to-many relationship is used to define relationships where a single model #endif // POST_HPP -Remember, TinyORM will automatically determine the proper foreign key column for the `Comment` model. By convention, TinyORM will take the "snake case" name of the parent model and suffix it with `_id`. So, in this example, TinyORM will assume the foreign key column on the `Comment` model is `post_id`. +Remember, TinyORM will automatically determine the proper foreign key column for the `Comment` model. By convention, TinyORM will take the "snake_case" name of the parent model and suffix it with `_id`. So, in this example, TinyORM will assume the foreign key column on the `Comment` model is `post_id`. Once the relationship method has been defined, we can access the `QVector` of related comments by Model's `getRelationValue` method: @@ -346,7 +346,7 @@ If your parent model does not use `id` as its primary key, or you wish to find t return belongsTo("foreign_key", "owner_key"); } -The third `belongsTo` parameter is the relation name, if you pass it, the foreign key name will be determined from it. By convention, TinyORM will "snake case" this relation name and suffix it with a `_` followed by the name of the parent model's primary key column to generate foreign key, the `__func__` predefined identifier is ideal for this. The relation name is also used in BelongsTo's `associate` and `disassociate` methods: +The third `belongsTo` parameter is the relation name, if you pass it, the foreign key name will be determined from it. By convention, TinyORM will "snake_case" this relation name and suffix it with a `_` followed by the name of the parent model's primary key column to generate foreign key, the `__func__` predefined identifier is ideal for this. The relation name is also used in BelongsTo's `associate` and `disassociate` methods: /*! Get the post that owns the comment. */ std::unique_ptr> diff --git a/docs/tinyorm/serialization.mdx b/docs/tinyorm/serialization.mdx index 091bb4af4..7ae7e3dc9 100644 --- a/docs/tinyorm/serialization.mdx +++ b/docs/tinyorm/serialization.mdx @@ -182,7 +182,7 @@ Occasionally, when converting models to vector, map, or JSON, you may wish to ad } }; -If you would like the accessor to always be appended to your model's vector, map, and JSON representations, you may add the attribute name to the `u_appends` data member set of your model. Note that attribute names are typically referenced using their "snake case" serialized representation, even though the accessor's method name is defined using "camel case": +If you would like the accessor to always be appended to your model's vector, map, and JSON representations, you may add the attribute name to the `u_appends` data member set of your model. Note that attribute names are typically referenced using their "snake_case" serialized representation, even though the accessor's method name is defined using "camelCase": #include