Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Static mappings #76

Open
skynet2 opened this issue Nov 21, 2018 · 2 comments
Open

Static mappings #76

skynet2 opened this issue Nov 21, 2018 · 2 comments

Comments

@skynet2
Copy link

skynet2 commented Nov 21, 2018

Hi @trenoncourt ,

Thanks for your awesome library.
In the scope of our project, we decided to use it as a replacement for graphql api.

But there is a problem, our system-wide standard is snake case, so all response properties are converted in a snake case using json.net. But in order this library to work we had to pass property name in CamelCase (as we have in c# code).

After some research, we implemented a solution to add an ability to have a static mapping for your library.

We`ve created an entity framework mapping builder which uses attributes from entity framework to correctly map properties.

Can you please take a look at commit skynet2@9389311

If it`s okay to have in public repo for your library, I can add some tests and create a pull request.

Thanks,
Stas

@trenoncourt
Copy link
Owner

hi @skynet2,

Thank you for your interest in AQ.
Please use develop branch for pull request, it has the last changes.

Are you going to add a new AutoQueryableSettings to enable/disable snake case ?

I saw no reference to ef package and this is fine because AQ works directly on top of iqueryable to have a maximum of compatibility.

thanks

@skynet2
Copy link
Author

skynet2 commented Nov 21, 2018

Hi @trenoncourt ,

Okey, i`ll take develop branch.

In fact, snake_case will be supported only by static mapping and entity build (at the current time)

Yep, i don`t want to add a reference to EFCore package, that's why during the creation of static maps I use reflection to take properties, methods from DB context.

============
I have one more question, what do you think about removing such properties as
IClauseValueManager ClauseValueManager { get; }
IQueryable TotalCountQuery { get; }
from IAutoQueryableContext.
Im not very familiar with your project yet, but my idea is having AutoQueryableContext as singleton. The reason for this is that im not using asp.net, we build our own rpc protocol on top of RabbitMQ.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants