Settings for scaffolding out an entity for your Web API.
A list of database entities in your project. These entities are added as dbsets to your database context, so they translate 1:1 to tables in your database.
|Name||Yes||The name of the entity||None|
|Properties||Yes||A list of properties assigned to your entity described in the entity properties section.||None|
|Plural||No||The plural of the entity name, if needed (e.g. ||Entity Name appended with an |
|Lambda||No||The value to use in lambda expressions for this entity.||First letter of the entity name.|
|TableName||No||The name of the table in the database.||Defaulted to the singular |
|Schema||No||The schema to use in the database.||None, which will equate to |
A list of properties that can be assigned to an entity.
|Name||Yes||The name of the property||None|
|Type||Yes||The data type for the property. These are not case sensitive and they can be set to nullable with a trailing ||None|
|IsPrimaryKey||Yes||When true, the property will be set as the primary key for the entity. For now, only one primary key is supported, with plans to add compound key support down the road.||false|
|CanFilter||No||Will set the property to be filterable in the API endpoint when set to true.||false|
|CanSort||No||Will set the property to be filterable in the API endpoint when set to true.||false|
|IsRequired||No||When true, the property will be set as required in the database.||false|
true for primary key
|ColumnName||No||The database field name for the given property.||None|
|CanManipulate||No||When set to false, you will not be able to update this property when calling the associated endpoint. When set to ||true|
false for primary key
|DefaultValue||No||Allows you to add a default value to a property. Note that it should be entered exactly as you'd want it, so a string would be something like ||None|
|ForeignKeyPropName||No||When adding an object linked by a foreign key, use ||None|
This example would create a supplier entity with several properties. Note:
SupplierIdis marked as a primary key
Entities: - Name: Supplier Properties: - Name: SupplierId IsPrimaryKey: true Type: int CanFilter: true CanSort: true - Name: Name Type: string CanFilter: true CanSort: true - Name: EmployeeCount Type: int? CanFilter: true CanSort: true - Name: CreationDate Type: datetime? CanFilter: true CanSort: true - Name: SupplierType Type: int? CanFilter: true CanSort: true - Name: IsVip Type: bool? CanFilter: true CanSort: true DefaultValue: false
Now let's say that we had a
Sale entity that has a
ProductId property that acts as a foreign key to another 'Product' entity:
Entities: - Name: Sale Properties: - Name: SaleId IsPrimaryKey: true Type: int CanFilter: true - Name: ProductId Type: int CanFilter: true - Name: SaleDate Type: DateTimeOffset? CanFilter: true - Name: SaleAmount Type: int CanFilter: true
If we wanted to return the product in our responses, we could add an additional
Product property of type
Product that links to the primary key of
ProductId in our
If possible, it is recommended that you avoid returning the foreign key object directly in an entity response like this. Instead, have your front end call each necessary endpoint or build a domain object that build this out separately.
Entities: - Name: Sale Properties: - Name: SaleId IsPrimaryKey: true Type: int CanFilter: true - Name: ProductId Type: int CanFilter: true - Name: SaleDate Type: DateTimeOffset? CanFilter: true - Name: SaleAmount Type: int CanFilter: true - Name: Product Type: Product ForeignKeyPropName: ProductId
Note that adding foreign keys will currently break the
Updateintegration tests as described in issue #2.
For the time being, composite keys can not be created using Craftsman commands. With that said, you are more than welcome to scaffold out an entity with one of the keys and then modify the generated entity, repository, tests, etc. to accommodate that composite key.