2

is it possible in entity framework to have something like an auto-incremented Id but with own rule?

I want to create a table where the Id looks like:

customer-license + underscore + incrementing number

(Only, if the dataset is created by customer)

the customer-licenses are stored in another entity called License (each customer gets one license)

LicenseId (str) | Customer (str)
---------------------------------
L0000           | DefaultData
L0001           | Customer 1
L0002           | Customer 2
L0003           | Customer 3

Wanted Resut:

So a dataset would look like:

Id (str) | Name (str)
----------------------------------
1        | Defaultdata-Dataset
L0002_1  | Dataset1 created by Customer 2
L0003_1  | Dataset1 created by Customer 3
L0002_2  | Dataset2 created by Customer 2

So, in time when I worked with Java and Hibernate, I could create a generator that builds my Id. In entity framework we have something like [DatabaseGenerated()] that needs a value from DatabaseGeneratedOption-enum. So it's not possible to use this.

Did someone tried to do something like this. No need for getting the license-ident as prefix (it's just for explaining my target) - how to define an ident-generator would be great.

Matthias Burger
  • 5,549
  • 7
  • 49
  • 94
  • Why do you want this as an ID (I suppose you mean PK as well)? Why can't it be an extra column? – CodeCaster Aug 08 '17 at 12:25
  • https://www.experts-exchange.com/questions/28125214/How-to-create-custom-ID-generator-for-Entity-Framework.html – Harsh Aug 08 '17 at 12:26
  • @CodeCaster default-data could be changed with my migration-framework. customers data is not allowed to get changed by migration. but they can be changed if the customer needs it. So I know which datasets due to the PK contains the license-Id. PK because of copying data from one database to another database - the PK must not change when copying. – Matthias Burger Aug 08 '17 at 12:31
  • Noooo @CodeCaster EF 4 is old as f*** - EF7 / EF Core is meant – Matthias Burger Aug 08 '17 at 12:32
  • The principles don't change. Override `SaveChanges()` and perform your logic there. – CodeCaster Aug 08 '17 at 12:32
  • I hate people just throwing round with "duplicated" less than 10 minutes after the question was written ... sorry, but it's not the solution I'm searching for. Not all tables will get this Id. So SaveChanges() is not an option. – Matthias Burger Aug 08 '17 at 12:35
  • Time has no relations to duplicates. The duplicates answer your exact question: override `SaveChanges()` and generate a primary key for added entities of the types for which you want to do that. If that isn't feasible, you should [edit] your question to very explicitly explain why not. – CodeCaster Aug 08 '17 at 12:39
  • @CodeCaster that's ridiculous. The duplicate doesn't answer my question, and I explained why. EF4 is not EF core. And as I mentioned, overriding `SaveChanges()` is NOT an option here. If/else for 200 tables is an option for you? not for me. But yeah, searching my answers somewhere else. – Matthias Burger Aug 08 '17 at 12:47
  • 1
    No, it's not ridiculous. Again, the duplicates answer the question that you are currently asking. The de facto way to do this with Entity Framework has always been and will always be to override `SaveChanges()` (or to implement a repository pattern that assigns a PK just before saving). You should at least mention in your question this isn't about one but two hundred entity types. Other design patterns apply there, especially if the PK generation rules differ per table. – CodeCaster Aug 08 '17 at 13:36
  • So I implemented a pattern that does completely what I need - without overriding SaveChanges(). - Too bad this question was closed. – Matthias Burger Aug 09 '17 at 10:03

0 Answers0