RE: Entity Framework - the lay of the land

People always use banks as the canonical example, but I had one at a local bank where I went to an ATM and did a transfer “From Account” -> “To Account” where both accounts were with the same bank. Came out of the “from”, and never went into the “to”. After what seemed like hours on the phone,

RE: Entity Framework - the lay of the land

I remember many years ago, connecting the devs to the DB via a dial-up 64kB modem. Worked wonders for the code that came back. Suddenly they noticed every call. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web:

Xamarin update warning

Folks, on Friday Xamarin Studio told there were updates available, this happens every month or so, so I said "sure" and let it go. This morning I find compile errors relating to casts, arrays and IEnumerable that make no sense, like the compiler has become stupidly aggressive. Then I discover I

Re: Entity Framework - the lay of the land

Correct, in a web app for example, you can often do very short lived caching for the life of a request. On Mon, Sep 19, 2016 at 11:39 AM, Tony Wright wrote: > I do like caching. And you often don't need to cache for very long anyway > to get significant benefits. > T. > >

Re: Entity Framework - the lay of the land

I do like caching. And you often don't need to cache for very long anyway to get significant benefits. T. On Mon, Sep 19, 2016 at 11:35 AM, Paul Glavich wrote: > Cache invalidation can be hard in tight race conditions and a few others. > There are many instances

RE: Entity Framework - the lay of the land

Cache invalidation can be hard in tight race conditions and a few others. There are many instances where it can be very easy based on use cases and data needs. I have used it to great effect for many years. Like you mentioned, do not write off because it can be hard. Kinda like designing

Re: Entity Framework - the lay of the land

> > I had an argument internally that caching was good, with the alternate > side saying that “cache invalidation” was hard so they never use it. > I think it is "hard" but don't write it off completely. Search for "second level cache" and you'll see it's not that trivial to use properly. Some

RE: Entity Framework - the lay of the land

>> Finally, caching is your friend. I'm called in all the time to help with >> concurrency and scale issues. The #1 way to get a DB to scale is to stop >> talking to it in the first place. Boom. I have been advocating that for years. That line is almost exactly the one I used in my performance

Re: Entity Framework - the lay of the land

Simple examples are anything many to many. If I have passengers on flights, I might have a Flights table, a Passengers table and perhaps some sort of FlightManifests table (who's on which flights). But I sure wouldn't want those three as objects. I'd probably want a Passenger object with a

Re: Entity Framework - the lay of the land

:-) Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com On Sun, Sep 18, 2016 at 5:57 PM +1000, "noonie" > wrote: How

Re: Entity Framework - the lay of the land

How to bridge the app/db gap, simple, learn about your enemy & make her your friend. Cooperate, Communicate, Collaborate Sometimes it works ;-) -- noonie On 18 September 2016 at 14:28, Greg Keogh wrote: > GL > > If your table design matches your object design, at least