IStandardSqlStatementOptionsBuilder there is no way to set the where clause about fastcrud HOT 17 CLOSED

I am guessing the BatchDelete should have IConditionalSqlStatementOptionsBuilder instead.

from fastcrud.

That's correct. Batch update and delete are part of the new set of features and I'm just about to write some tests for them.

from fastcrud.

I was just about to send a Pull request - still want it? That was just updating Dapper Extensions.

from fastcrud.

yeah sure

from fastcrud.

Got to it eventually. I've added tests for both batch delete and batch updates.

from fastcrud.

Oops - sorry i had the pull request create screen open - but forgot to commit and got slammed in meetings. Thanks for adding it.

from fastcrud.

No worries. I'm waiting for the build to finish now. While adding the tests for batch update/delete, I discovered a very strange behavior of the compiler when dealing with string interpolation.

var interpolatedString = $"something there {whatever}";
interpolatedString will actually be resolved as a string! In the code we're using like
var finalString = $"something there {whatever}".ToString(SqlFormatter)
but what was happening under the hood, the string's version of the ToString was called, which was simply ignoring the formatter.
I've changed the code to perform the resolve via a function that requires a FormattableString and it seems to force the compiler to still keep it as such. Very very strange.

from fastcrud.

That is weird. I have a question for you - never used the myget tool - when you commit something like this bug fix. Is this automatically available in nuget as a new build or do you have to push it manually?

from fastcrud.

It's got its own NuGet feed. It can be configured to push either automatically or manually from its feed to nuget.org. For the time being I chose the latter.

What's driving me nuts is its very poor build system, which works fine for simple projects. As soon as you want something a bit different, you're in a world of pain. For FastCrud I had to include a powershell script to build, run the tests with the LocalDb and SqLite, and create the NuGet packages (MyGet.ps1).

from fastcrud.

Published in Build 69.

That's all I wanted to include in this version. If everything is quiet I'll promote this to a release version in about a week.

For 2.3 I'll focus on JOINs.

I'm using this library in a repository pattern, which I will port at some point into an addon to this library. Using a mapper from the DB layer to the business layer or directly to the UI layer, my repositories create on the fly entity mappings for the business/dto entities which are then being passed down to FastCrud for partial selects and updates.

from fastcrud.

Awesome - i will get the latest nuget. Thanks again.

from fastcrud.

Hey. Do you mind sharing how your rest of the data access layer looks like if possible. What do you mean by on the fly entity mappings.

I am building new data access strategy currently for my company, i am also using a repository pattern which in turn calls fastcrud. So far i am happy w what i have come up with.

My repository is a hybrid of dapper/fastcrud and entity framework, ef for supporting legacy queries using lambda expressions and expression helpers that we have everywhere. So unless there is a solid expressions to sqlbuilder available, i am relying on using ef for those queries.

On Nov 23, 2015, at 5:36 PM, MoonStorm [email protected] wrote:

Published in Build 69.

That's all I wanted to include in this version. If everything is quiet I'll promote this to a release version in about a week.

For 2.3 I'll focus on JOINs.

I'm using this library in a repository pattern, which I will port at some point into an addon to this library. Using a mapper from the DB layer to the business layer or directly to the UI layer, my repositories create on the fly entity mappings for the business/dto entities which are then being passed down to FastCrud for partial selects and updates.

—
Reply to this email directly or view it on GitHub.

from fastcrud.

Sorry I can't share the code. I'm gonna have to rewrite it. But we can talk about it.

The mapper idea is not new. I could've picked any mapper that's out there to map DB entities to DTOs or business layer entities but I saw an opportunity here so I created one of my own. It's not a big deal really. A Mapping<TDbEntity, TDto> can be instructed to perform one-to-one property mappings, many-to-one via callback functions, and hopefully soon enough I'll be able to bring into the mix multiple db entities joined together as a dto could cover more than one db entity. The mapper is then passed over to a generic repository.

For example let's look at a Users table. For authentication I would need the user id, login name and password (key, salt, etc). Hence I'd create a mapping between the UserDbEntity and a UserLoginDto, grabbing only what I need from the db entity. Other than authentication, I will probably work a lot with a UserDto entity, which will contain the display name and the user id, the display name being a combination of first name and last name. Another mapping can thus be created between the same UserDbEntity and a UserDto. Of course you can get creative with it, use inheritance for the mappings, attach validation rules (I'm using FluentValidate), etc.

Under the hood the mapper knows what properties I'm going to need on both sides, hence it's able to create the db entity mappings used by FastCrud. So for the UserLoginDto it'll instruct FastCrud to perform just a select for UserId, LoginName and Password, it'll then copy the one-to-one property values or call the registered callbacks to create the final dto from the partially selected db entity. All these via a Repository<UserLoginDto> that exposes pretty much the same CRUD methods as FastCrud , but this time working at an upper level. A DB connection factory joins the party as well at this stage.

Obviously my story isn't the same as yours so I'm not sure how much of these would be useful to you. I didn't have to deal with EF in my current project, and I can't even imagine the hurdles you must be going through trying to marry it with something else. I always liked though the idea of having a "mirror" of the db in terms of generating entities with a T4 template, so my workflow goes something like this:

1. Update the DB
2. Run the T4 templates and re-create the db entities. Being type safe everywhere I'll know compile time if something broke somewhere.
3. Create/update the db to dto mappers but never touch the generated db entities. Reason why the library didn't initially support column name overrides. I simply didn't need them.
4. Create/update the logic inside the business layer services that internally all use these repositories I mentioned earlier.

from fastcrud.

That is cool - its simple and very efficient. The mapping and creating DTO's is the only thing that is the extra work but makes it much more efficient so makes it worth it IMO.

I cannot really do that as i am dealing with a bunch of legacy code that i am refactoring and making it work on top of a new DA / service layer. So all that code expects the DB entities back.

Yea, i just finished doing the hybrid of EF and dapper fastcrud working. Took me a long time and a bunch of gotcha's to get through it. I am pretty much using EF as readonly, and do all my writes through fastcrud, that way i do not have to maintain a context and worry about the lifetime etc.

Thanks for sharing your strategy.

from fastcrud.

I'm dealing with a similar problem. I'm fairly certain though that in the future someone else is gonna look horrified at my code as paradigms and patterns are continuously changing 😆 You can never get bored! 😆

from fastcrud.

Before you start complaining, I just renamed the methods Batch* to Bulk*, so please update to Build 73 and adjust your code. Sorry for that but I realized the name for those methods was misleading.

from fastcrud.

No worries - i realize we are at a beta with these new changes and expect some changes.

from fastcrud.