|
We had a mismatch during development where a new column existed in DEV but not yet in TEST. No matter, we weren't using it in this test so our filter didn't use it, no problem. Except EF generated SQL to ignore it by referencing it! Boom!
Straight SQL worked fine, of course.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
If your solution uses DI and you create ambiguous constructors then the only possibly outcome is failure. That's not a failure of DI, it is you using it in ways it is not intended to work. You can't throw a bike off a cliff and complain it didn't float to the ground.
As for getting services you've added to the service collection you use IServiceProvider to do that, the service collection is exactly what it says, a collection of services. If you want a given service you get it from the service provider.
As for EF and direct\raw SQL etc, EF is an ORM, if need to use raw sql, stored procs etc then it is the wrong tool for the job.
So use the right tool for the right job, and use those tools as they are intended to be used and you'll be fine.
|
|
|
|
|
Quote: throw a bike off a cliff Why do you think his name is Clifton
|
|
|
|
|
F-ES Sitecore wrote: If your solution uses DI and you create ambiguous constructors then the only possibly outcome is failure.
Pardon me for taking exception to this, but that's BS. I've written DI's and you go for the most specific instantiator you can with the information you have in the service manager. You don't go from general to specific, or simply barf in the bowels of your injector with no intelligible message.
F-ES Sitecore wrote: As for getting services you've added to the service collection you use IServiceProvider to do that
Right. So you have one thing for adding services, but another thing for getting them? BS.
F-ES Sitecore wrote: As for EF and direct\raw SQL etc, EF is an ORM, if need to use raw sql, stored procs etc then it is the wrong tool for the job.
And exactly why can't the tool do both gracefully? It's not the wrong tool. The tool is broken.
We have very different views, I see!
|
|
|
|
|
Marc Clifton wrote: you go for the most specific instantiator you can with the information you have in the service
Unless I misunderstood your original post you had two constructors with a single param, so how does the DI know which is "more specific"?
Marc Clifton wrote: So you have one thing for adding services, but another thing for getting them?
Yes, it's called the single responsibility principal. By separating the two if you want to use your own resolver, you can.
Marc Clifton wrote: why can't the tool do both gracefully?
Why can't my bike float me to the ground like a parachute? The more things a tool does, the worse it tends to be at them. EF can use SPs and raw SQL, but you're not going to have as much flexibility or control, so if you want to do anything advanced you're probably going to have a bad time.
|
|
|
|
|
F-ES Sitecore wrote: so how does the DI know which is "more specific"?
Well, one is of the form Foo<Bar> and the other is just Foo . That seems sufficient to distinguish which to use.
Oops, hit Post Message.
Quote: Yes, it's called the single responsibility principal. By separating the two if you want to use your own resolver, you can.
OK, point taken, though personally I find that to be a bit too much separation.
F-ES Sitecore wrote: EF can use SPs and raw SQL, but you're not going to have as much flexibility or control, so if you want to do anything advanced you're probably going to have a bad time.
Agreed, but in my case, I want to do something very specific and simple involving several table joins and I don't want to write the class models for each table so EF can make the query. For me, it's a case of the tool which as a method that looks like it should work but has severe limitations. Tools (we're talking software tools, not specious analogies) should not be designed so they get in the way when I want to take control, and shouldn't require me to write additional otherwise useless layers of code.
|
|
|
|
|
Marc Clifton wrote: Well, one is of the form Foo<Bar> and the other is just Foo . That seems sufficient to distinguish which to use.
What if it has both Foo and Foo<Bar> registered as services? How does it know which one you want? You should have added Foo to the param list of the existing constructor rather than create a new constructor with one param also. That's just how DI works.
|
|
|
|
|
Not really possible given it's a derived class:
public class CatalogContext : DbContext
{
public CatalogContext(DbContextOptions<CatalogContext> options) : base(options)
{
}
}
|
|
|
|
|
So given what you said, I tried something:
public CatalogContext(DbContextOptions opts2, DbContextOptions<CatalogContext> options) : base(opts2 ?? options)
That actually worked. Sort of gross though
Actually, the whole issue could be avoided if I'd done:
var dbBuilder = new DbContextOptionsBuilder<CatalogContext>();
instead of:
var dbBuilder = new DbContextOptionsBuilder();
|
|
|
|
|
Into the future, or the past, and, be present as an invisible observer: when/where would you go ?
I'll add my choice, later.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Well, hard to choose the future as we don't know what events will occur...
So I will go back in time and watch the dinosaurs get wiped out.
|
|
|
|
|
I would go back and just watch the dinosaurs live. People have speculated that the T-Rex was about as intelligent as a cat. Did it play with its prey as a cat does? Did it train it young to hunt? Inquiring minds want to know.
|
|
|
|
|
I'd use it to skip advert breaks on TV.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Get a DVR. Start watching after the show is over. then power through the commercials. Works for me.
ZZZZZZZ
|
|
|
|
|
We have a Sky box which does that. Unfortunately I also have Herself, who doesn't.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yes. My wife seems to enjoy the commercials more that the shows too.
That's why we don't watch much TV together. She also insists on commenting on all of the action while it is happening!
I will never understand women ...
SWMBO runs my life for me.
|
|
|
|
|
30AD, Jerusalem.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
To see what the Romans had done for them?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
No - just to see who's hanging around...
This space for rent.
|
|
|
|
|
I think it would be interesting to attend my own funeral
<sig notetoself="think of a better signature">
<first>Jim</first> <last>Meadors</last>
</sig>
|
|
|
|
|
So...you know the exact date of your own demise?
Although I suppose you could go far enough into the future to look up your own obituary, then go back to that date...
But my question is...what would you be trying to learn by attending your own funeral...? I think the risk is that, were it possible, it could fundamentally change what you think of some people, even closest friends and relatives...would you risk it?
|
|
|
|
|
If your best friend did not go to your funeral would you go to theirs?
Oh, yes, I would definitely drag my rotting carcass to their funeral just to see everyone else freak out.
|
|
|
|
|
I'm more like Woody Allen: I'm not afraid of dying - I just don't want to be there when it happens.
|
|
|
|
|
I'd go way back to the moment life began on Earth. Not human life or dinosaurs or insects... the very first spark of life.
The Beer Prayer - Our lager, which art in barrels, hallowed be thy drink. Thy will be drunk, I will be drunk, at home as it is in the tavern. Give us this day our foamy head, and forgive us our spillage as we forgive those who spill against us. And lead us not to incarceration, but deliver us from hangovers. For thine is the beer, the bitter and the lager, for ever and ever. Barmen.
|
|
|
|
|
smoosh it and save everyone the hassle.
“The story so far:
In the beginning the Universe was created.
This has made a lot of people very angry and been widely regarded as a bad move.”
― Douglas Adams, The Restaurant at the End of the Universe
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|