Skip to content
This repository has been archived by the owner on Apr 17, 2019. It is now read-only.

KORM - ideas and suggestions for new features #177

Open
satano opened this issue Jan 8, 2019 · 0 comments
Open

KORM - ideas and suggestions for new features #177

satano opened this issue Jan 8, 2019 · 0 comments

Comments

@satano
Copy link
Member

satano commented Jan 8, 2019

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:

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.

@satano satano self-assigned this Jan 8, 2019
@Burgyn Burgyn self-assigned this Feb 7, 2019
@Burgyn Burgyn pinned this issue Feb 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants