Rather than requiring a custom Map attribute, this should support the Table attribute from System.ComponentModel.DataAnnotations.Schema.
This is from the System.ComponentModel.Annotations package, so any ORM is allowed to use it.
+1
maybe also ColumnAttribute ?
I am not prioritizing this for now, please advise if this is not enough. It does the job as you pointed here.
but why reinvent the wheel ? is there any special reason ?
The benefit of supporting System.ComponentModel.DataAnnotations.Schema is that it would make it easier to port code from other ORMs to yours.
For example, you could just drop-in a EF or EF Core class that was declared with those attributes and it would more or less just work.
I'm not suggesting removing what you already have, as that would break backwards compatibility. It's just a suggestion for making entity classes more portable. It's like how all the serialization libraries now honor [DataContract] and [DataMember] in addition to their own attributes for advanced cases.
Really makes sense. I may be doing this, but not for now because the impact is a bit high due to the fact that it is in Core of RepoDb.
Also, it requires me to rewrite/retests thousands of Unit and Integration Tests.
For now, this is not feasible, but the support might be done in the future. No timeline yet.
I made a gist to use Table/Column attributes (mostly so I can use different casing), it's just for my own use-case, but you can edit it as you see fit. It's required that you use the latest beta version which has support for Class/PropertyMapping.
https://gist.github.com/lauw/20747e47e373444432278985e8eee495
Add the gist to your project and call it:
RepoDbMapper.MapTablesAndColumns(NameCasing.SnakeCase);
Awesome editions you made, let me assess if we can consider putting your code in the core of RepoDb. Seems to be awesome.
As you mentioned about latest beta release, it is now supporting a feature called Implicit Mapping in which it allows you to map the following via class mappers.
Still I am waiting an update to a guy that would contribute a class called ClassMap
In anyway, please feel free to explore the Implicit Mapping from the official site.
The actual thread can be found at #415 .
I am planning to open this one as for-grabs.
@lauw - I would assume that the Attributes has a higher precedence than using the Mappers as it is explicitly being annotated. Btw, supporting a Table and Column data annotation seems to be very easy in RepoDb. I can guide you 2 liner changes to add the support for this, but you have to write Unit Test (and maybe Integration Tests).
Are you open to make a PR for this? The changes is on the following code lines.
@mikependon Great! :) I'm willing to take a look at it later this week, will first see if it doesn't cost too much time with the tests. This wasn't the reason I made the mapper though, it was mostly to support snake_case and I needed a way to annotate my db objects.
@lauw - what you had done is a really cool stuff. No need for a rush for now, there are current activities on the library when it comes to Implicit Mapping, as you mentioned above (you need to reference the latest). But TBH, there is one user that approached me about snake casing support - and I find it not really a common case, but it seems.
Would you be able to save your gist for future PR here? I am thinking to integrate that snake_case logic you did for Implicit Mapping (once the PR for FluentMapper
I'm willing to take a look at it later this week, will first see if it doesn't cost too much time with the tests.
Well, the tests are not that extensive, you may have to extend these 2 unit tests files.
And may create additional integration test that has a completely the same contents, except that you are using the Table and Column attribute rather than Map. Here is the integration test that you can copy over. TBH, I did the same with implicit mapping test.
@lauw - hey mate, are you still open for a PR of this? :)
This is now fixed via PR #435. This will be available on the next beta RepoDb >= v1.11.1-beta2.
@cwaldron - please do let me know if you need a beta build right away.
Just added an extensive Integration Tests for this. The tests can be found here.
In addition, the Unit Tests for Key/Primary and Table/Column/Map collisions has also been added/extended.
The fix is now available in version RepoDb v1.11.1.
The latest release of RepoDb is now including this request. Please install the version 1.11.2.
With this, I am closing this one now. Just revert if you have questions.
Most helpful comment
The benefit of supporting
System.ComponentModel.DataAnnotations.Schemais that it would make it easier to port code from other ORMs to yours.For example, you could just drop-in a EF or EF Core class that was declared with those attributes and it would more or less just work.
I'm not suggesting removing what you already have, as that would break backwards compatibility. It's just a suggestion for making entity classes more portable. It's like how all the serialization libraries now honor
[DataContract]and[DataMember]in addition to their own attributes for advanced cases.