Do not close this issue. This is a "meta issue". It is just for writing down any ideas and suggestions for KORM. Ideas here, once consulted, will be moved to separate issues.
Support for complex entities, whose properties are another objects
Now we only support one-to-one mapping of object's properties to data table columns. It is not sufficient. Often there are situations, where there is one table in database, but entity class does not have many primitive properties, but just some complex ones. For example invoice. In database it can be table with columns: Id, InvoiceNumber, SupplierName, SupplierAddress, PurchaserName, PurchaserAddress, but in code, it is represented by this classes:
public class ContractingParty
{
public string Name { get; set; }
public string Address { get; set; }
}
public class Invoice
{
public int Id { get; set; }
public string InvoiceNumber { get; set; }
// Sub-properties are mapped to `SupplierName` and `SupplierAddress` columns.
public ContractingParty Supplier { get; } = new ContractingParty();
// Sub-properties are mapped to `PurchaserName` and `PurchaserAddress` columns.
public ContractingParty Purchaser { get; } = new ContractingParty();
}
Simpler Delete of entities
Now, if we want to delete an entity, we can use direct SQL statement (ExecuteNonQuery), or DbSet. The disadvantage of ExecuteNonQuery is, that it does not have ane knowledge about entity type, so the SQL must be hand written. Disadvantage of DbSet is that we need to create an instance of the entity, just to have its ID. I'd like to have something which can be used without creating an entity instance:
_database.Delete<EntityType>(123)
Things to think about is where to implement this (IDbSet, IDatabase...). And it should at least support int and long primary keys (generic of <TEntity, TKey>?), but better any keys (even composite ones).
Value generators for columns
Now we have some support for generated primary keys. But we only support int (no long). It is achieved by Key attribute. It woul be better to have something like ValueGenerator attribute, which will generate value for column on INSERT. And it could be used for any column, not just primary key.
Timestamp column
This would be special column (for start marked with some attribute) of DateTime/DateTimeOffset type. Value for this column would be automatically set to current date and time on every INSERT or UPDATE.
Use ConnectionStrings section with named connection strings
We use our own setup of connection string in setting. We require ConnectionString section with ProviderName and ConnectionString subkeys. We could use default connection strings settings (as Entity Framework does it). The section name is ConnectionStrings and subkeys are name of connection strings. Provider can be integrated in connection string itself. When creating IDatabase, connection string name will be specified. If the name is not specified, default name DefaultConnection will be used.
Use different kind of configuration than attributes
Now some configuration is allowed only using attributes (Key, Alias). Something can be changed using custom ModelMapper. Maybe we can think about different kind of configuration instead of attributes.
General info
Do not close this issue. This is a "meta issue". It is just for writing down any ideas and suggestions for KORM. Ideas here, once consulted, will be moved to separate issues.
Support for complex entities, whose properties are another objects
Now we only support one-to-one mapping of object's properties to data table columns. It is not sufficient. Often there are situations, where there is one table in database, but entity class does not have many primitive properties, but just some complex ones. For example invoice. In database it can be table with columns:
Id
,InvoiceNumber
,SupplierName
,SupplierAddress
,PurchaserName
,PurchaserAddress
, but in code, it is represented by this classes:Simpler
Delete
of entitiesNow, if we want to delete an entity, we can use direct SQL statement (
ExecuteNonQuery
), orDbSet
. The disadvantage ofExecuteNonQuery
is, that it does not have ane knowledge about entity type, so the SQL must be hand written. Disadvantage ofDbSet
is that we need to create an instance of the entity, just to have its ID. I'd like to have something which can be used without creating an entity instance:Things to think about is where to implement this (
IDbSet
,IDatabase
...). And it should at least supportint
andlong
primary keys (generic of<TEntity, TKey>
?), but better any keys (even composite ones).Value generators for columns
Now we have some support for generated primary keys. But we only support
int
(nolong
). It is achieved byKey
attribute. It woul be better to have something likeValueGenerator
attribute, which will generate value for column onINSERT
. And it could be used for any column, not just primary key.Timestamp column
This would be special column (for start marked with some attribute) of
DateTime
/DateTimeOffset
type. Value for this column would be automatically set to current date and time on everyINSERT
orUPDATE
.Use
ConnectionStrings
section with named connection stringsWe use our own setup of connection string in setting. We require
ConnectionString
section withProviderName
andConnectionString
subkeys. We could use default connection strings settings (as Entity Framework does it). The section name isConnectionStrings
and subkeys are name of connection strings. Provider can be integrated in connection string itself. When creating IDatabase, connection string name will be specified. If the name is not specified, default nameDefaultConnection
will be used.Use different kind of configuration than attributes
Now some configuration is allowed only using attributes (
Key
,Alias
). Something can be changed using customModelMapper
. Maybe we can think about different kind of configuration instead of attributes.