6 ms·

Years ago, over a decade ago now, I was a .Net developer. Microsoft introduced Entity Framework, their new way of handling data in .Net applications. Promises m

Years ago, over a decade ago now, I was a .Net developer. Microsoft introduced Entity Framework, their new way of handling data in .Net applications. Promises made, promises believed, we all used it. I was especially glad of Lazy Loading, where I didn't have to load data from the database into my memory structures; the system would do that automatically. I could write my code as if all my memory structures were populated and not worry about it. Except, it didn't work consistently. Every now and again a memory structure would not be populated, for no apparent reason. Digging deep into technet, I found a small note saying "if this happens, then you can check whether the data has been loaded by checking the value of this flag and manually loading it if necessary" [0]. So, in other words, I have to manually load all my data because I can't trust EF to do it for me. [1] Long analogy short, this is where I think AI for coding is now. It gets things wrong enough that I have to manually check everything it does and correct it, to the point where I might as well just do it myself in the first place. This might not always be the case, but that's where I feel it is right now. [0] Entity Framework has moved on a lot since then, and apparently now can be trusted to lazily load data. I don't know because... [1] I spat the dummy, replaced Windows with Linux, and started learning Go. Which does exactly what it says it does, with no magic. Exactly what I needed, and I still love Go for this.

nercury 2y ago
Pardon me for the tangent (just a general comment not directed to OP). What I have learned over the years is that the only way to properly use ORM is as a fancy query tool. Build the query, fetch/update data, MOVE THE DATA to separate business objects. Don't leave ORM entities shared across the sea of objects! Phew, thanks, I got that off my chest.
- rafaelmn 2y ago
  That doesn't really help you with EF because there's plenty of stuff shared at context level. So depending on the order of queries in the context the same query can return different data. I hate EF and everything it stands for. :)
  - nercury 2y ago
    Yeah, in a web app, one context per request. In desktop app... I have never used EF there.
- noduerme 2y ago
  adding an off the shelf ORM layer creates so much more opacity and tech debt than writing queries I don't understand why anyone would willingly put one into their stack. Sure, they're neat although I don't even know if they save time. There's something very satisfying about well-crafted queries. And is it ever really well crafted if you can't tweak them to improve their their execution plan? I've never had a client or boss who asked to use an ORM framework. I suspect it's something people think looks cool - treating SQL as OOP - until they run into a problem it can't solve. [edit] for instance, I have a case where I use a few dozen custom queries on timers to trawl through massive live data and reduce it into a separate analytics DB. Using everything from window functions to cron timers to janky PHP code that just slams results from separate DBs together to provide relatively accurate real-time results. At the end from that drastically reduced set in the analytics DB... sure, I'm happy to let the client summarize whatever they want with Metabase. But those things just couldn't be done with an ORM, and why would I want to?
  - bad_username 2y ago
    For me the biggest reason is automated database initialization and migration. After defining or updating the ORM model, I don't have to worry about manually CREATing and ALTERing tables as the model evolves. This is compatible with the OC suggestion of using ORMs as a "fancy query builder" and nothing more, which I strongly support.
    - noduerme 2y ago
      I'm not sure if you're talking about creating and altering model tables or if you mean ORMs provide safety in case underlying tables are modified. I'd argue that well-built queries should be resistant to alteration of the underlying tables, and that views and functions and stored procedures already exist to both red flag breaking changes and also to combine and reduce whatever you need without relying on third party code in another language layer to do the lifting.
    - blksv 2y ago
      Doesn't it also mean that any non-trivial migration (e.g. which requires data transformation or which needs to be structured to minimize locking) has to be defined elsewhere, thus leaving you with two different sources for migrations, plus some (ad-hoc) means to coordinate the two? (I would say that it is conceptually perverse for a client of a system to have authority over it. Specifically, for a database client to define its schema.)
- marcus_holmes 2y ago
  Agree completely, as does most of the Go community :) Newbie gophers are regularly told to learn some SQL and stop trying to rebuild ActiveRecord in Go ;) But in .Net, EF is still the most common way of accessing data (I have heard, because I stopped using it over a decade ago).
  - deleted 2y ago
    [deleted]
  - lomase 2y ago
    EF is the common way of saving data.
- arrowsmith 2y ago
  I wouldn't have believed you until I moved from ActiveRecord (Rails's ORM) to Ecto (Elixir/Phoenix's data mapping library which is decidedly not an ORM.) It's a million times better and I'm never going back.
  - cultofmetatron 2y ago
    same, I wish more libraries would go the ecto design route. my ecto queries map pretty close to 1:1 with the sql counterpart. no guessing what the output is going to look like. I spend my time debugging the query and not trying to get the orm to output he query I want.
    - arrowsmith 2y ago
      Yeah, I hear some people say that they find Ecto.Query confusing, and I think it's because they never learned SQL properly. That's understandable because it's possible to use something like ActiveRecord for years without ever learning to write even a simple SQL query. But if you have a good grasp of SQL then Ecto.Query is trivial to learn - it's basically just SQL in Elixir syntax.
      - cultofmetatron 2y ago
        > it's basically just SQL in Elixir syntax. its sql in elixir syntax with a bunch of QOL improvements. for one thing, I can seperate my subqueries into separate variables ``` sub_q = from(l in Like) |> where([l], l.user_id == ^user_id) |> select([l], %{ user_id: l.user_id, likes_count: count(l.id) }) |> group_by([l], l.user_id) main_query = from(u in User) |> join(:left, [u], likes_count in ^subquery(sub_q), on: likes_count.user_id == u.id, as: :likes_count) |> select([u, likes_count: l], %{ name: u.name, likes: l.likes_count, }) |> where([u], u.id == ^user_id) user = main_query |> Repo.one() ``` Being able to think directly in sql lets you perform optimal queries once you understand sql. and imho, this much cleaner than tha equivalen sql to write. it also takes care of input sanatization and bindings.
    - freedomben 2y ago
- specialist 2y ago
  > use ORM is as a fancy query tool As an alternative to query-by-example (QBE)? https://en.wikipedia.org/wiki/Query_by_Example https://en.wikipedia.org/wiki/Query_by_Example
kaba0 2y ago
> and started learning Go. Which does exactly what it says it does, with no magic Too little abstraction is just as bad as too much.
- alrs 2y ago
  Assembly is too little abstraction. Go is not.
  - neonsunset 2y ago
    It is. Oh, and also, Go managed to screw up even the assembly, inventing portable but actually not dialect that uses ugly bits of AT&T syntax, custom operator precedence and in practice is non-portable, forcing you to mix Go-only mnemonics (which might even collide with opcode names on certain platforms), supported opcodes of target platform, and BYTE literals for opcodes it doesn't support, making a lot of your preliminary (N)ASM knowledge useless. Isn't that magnificent? Gee, I wonder if there's a better way to do so that is not such a lazy job. But doing it properly, like .NET does, is supposedly too much effort!
    - alrs 2y ago
      It would be great if C# could be discussed as a language on its merits, but Microsoft has been a terrible steward. It's too bad.
      - neonsunset 2y ago
        So you are saying it's even worse than suing anyone over using the language like a certain Java-related company or laying off people off the core language team like a certain Dart-related company?
- jimbokun 2y ago
  The amount of abstraction available in Go is just about right. It gives you higher level constructs, while still being reasonably straightforward to predict memory and CPU performance and behavior.
smokel 2y ago
A key difference between database mapping and interactive AI tools is the position of the user. I would not be enthusiastic about a system where I receive database query results for review, before delivering them to an end user somewhere on this planet. However, I am more than happy to get some extra help in communicating code from my brain to a compiler.
neonsunset 2y ago
And it’s by far the best one now that all the issues that made old EF unsound were solved in EF Core. Good developers know to appreciate that and wouldn’t want to touch Go ecosystem afterwards with a 10 feet pole.
LandR 2y ago
Well, this month we had to debug an issue where EF was NOT populating fields on classes from the db, that it definitely should have been! So it still seems flakey. I've never worked a single job that chose EF that didn't end up regretting it. Either from it being unreliable, migration hell or awful performance. "It allows you to treat your database like an in-memory enumerable" Then devs go and do exactly that and wonder why performance is so terrible... I hate EF.
- neonsunset 2y ago
  Which version?
  - LandR 2y ago
    We are currently on the latest. We had an issue last week where we had an obect like public class Foo { public List<Bar> Bars { get; set; } } We'd query for some Foos, like: await _dbContext.Foos.ToListAsync(); and some amount of them would have Bars be an empty list where it should definitely be populated from the db. And it wasn't even consistent, sometimes it would populate thousands, sometimes it would populate a handful and then just stop populating Bars. No errors, no exceptions, just empty lists where we'd expect data. And so often we have to debug and see what SQL its actually generating, then spend time trying to get it to generate reasonable sql, when if we were using sprocs we could just write the damn sql quicker. Another issue we have is the _EFMIgratoinsHistory table. Sometimes we will deploy and get a load of migration errors, as it tries to run migrations its already ran... SO they all fail and then the API doesn't come back up... The fix ? TUrn it off and on again and it stops trying to re-run migrations its already ran!
    - neonsunset 2y ago
      EF Core 8? Inconsistent behavior is not expected. Assuming you haven't missed to add an .Include[0], please consider submitting an issue(s) to https://github.com/dotnet/efcore https://github.com/dotnet/efcore [0] https://learn.microsoft.com/en-us/ef/core/querying/related-data/eager https://learn.microsoft.com/en-us/ef/core/querying/related-d...
kamaal 2y ago
>>It gets things wrong enough that I have to manually check everything it does and correct it, to the point where I might as well just do it myself in the first place. I have had personal experience with this. And seen others telling me as well. These AI things often suggest wrong code, or even with bugs. If you begin your work by assuming AI is suggesting the correct code you can go hours, to even days debugging things in the wrong place. Secondly when you do arrive at a place where you find the bug in the AI generated code, it can't seem to fix or even modify it, because it misses context in which the which itself generated at the first place. Thirdly the AI itself can interpret your questions in a way you didn't mean. As of now AI generated code is not for serious work of any kind. My guess a whole new paradigm of programming is needed, where you will more or less talk to AI in a programming language itself, some what like lisp. I mean a proper programming language at a very abstract level, which can be interpreted in only one possible meaning, and hence not subject to interpretation.
- cess11 2y ago
  "My guess a whole new paradigm of programming is needed, where you will more or less talk to AI in a programming language itself, some what like lisp. I mean a proper programming language at a very abstract level, which can be interpreted in only one possible meaning, and hence not subject to interpretation." Code generation is quite old though, and also quite common, also outside the Lisp-family. When doing non-trivial systems development in Java you tend to use it a lot, especially with XML as an intermediary, abstracted language.
Quothling 2y ago
> [0] Entity Framework has moved on a lot since then, and apparently now can be trusted to lazily load data To some degree. If you're using it for anything serious you're still going to help it along a lot. It's rather easy to do so, however, and I certainly wouldn't consider writing your own code as fast or easy as simply telling EF how you want it to do certain things. I'm not an overall fan of EF. I especially dislike how it's model builder does not share interoperability with other .Net libraries which also use it. I also don't really like the magic .Net does behind the scenes. EF as a whole has been one of the better ORMs for any language since .net core. I'd still personally much prefer something like Rust's diesel, but whenever I have to work with C# I tend to also use EF.
- Foobar8568 2y ago
  Diesel is not an ORM and a typical rust library...
  - kevthecoder 2y ago
    The strapline seems to suggest it is an ORM (I've not used Diesel yet): >Diesel: A safe, extensible ORM and Query Builder for Rust https://github.com/diesel-rs/diesel https://github.com/diesel-rs/diesel
- to11mtm 2y ago
  You might want to try Linq2Db, it is much closer to Diesel in how it works (More SQL DSL with parameter+reader mapper, less Unit-of-work ORM). FWIW, it can actually work 'on top' of an Existing EF Core context+mappings (i.e. if you have an existing project and want to migrate, or just need the better feature-set for a specific case.) or you can get pretty close to 'yolo by convention' depending on case. In general though it's a lot less ceremony to start messing around.
Foobar8568 2y ago
From what I remember, lazy loading wasn't part of EF for a long while and even longer for navigational properties. I am not even sure if it was part of EF4.
nurumaik 2y ago
>It gets things wrong enough that I have to manually check everything it does and correct it Thing is, reading code is way faster than writing code
- deely3 2y ago
  Huh, for me its always vice versa. When I'm not sure in the someones code I have to double or triple check it be sure that I understand it correctly and to verify that there no somehow hidden missed steps or side effects.
BaculumMeumEst 2y ago
Even more important than the question of productivity is that this turns a joyous activity into a depressing probabilistic shitshow where you describe what you're trying to do and hope for the best. Instead of feeling engaged and challenged, you're just annoyed and frustrated. No thanks!
whywhywhywhy 2y ago
I feel pre November “dev day” 90% of the time I could trust GPT4 output to just work but post downgrades the increased amount of times I’ve copy and pasted then seen the error and realized there’s unfinished placeholder stuff, straight up parts not done or previous code removed that was important. Just means I now spend a lot of time rewriting it which I could have just done in the first place but now I’ve wasted time asking GPT too.
naasking 2y ago
> Long analogy short, this is where I think AI for coding is now. It gets things wrong enough that I have to manually check everything it does and correct it, to the point where I might as well just do it myself in the first place. Even if that were true, reading code is reasonably faster than typing it out and then reading it again to check it.
dmix 2y ago
> this is where I think AI for coding is now. It gets things wrong enough that I have to manually check everything This might be dependant on the programming language, some languages are way more popular and have way more questions on StackOverflow and Reddit and repos on github, so the answers will be better. When I use copilot for JS it's right 90% of the time. And where it's 'wrong' it's usually just stuff it skipped over because it didnt have proper context.
rspeele 2y ago
Lazy loading was a mistake in EF. A lot of apps had awful performance due to lazy loading properties in a foreach loop creating N+1 queries to the database. It would be fine in dev with 50-100 rows and a localhost SQL and blow up in prod with 1000s of rows and a separate Azure SQL. Also if you relied on lazy loading properties after the DbContext had been disposed (after the using() block) you were out of luck. With old EF we would turn off lazy loading to make sure devs always got an exception if they hadn’t used .Include() to bring the related entities back in their initial query. Querying the database should always be explicit not lurking behind property getters. Fortunately with EF core MS realized this and it’s off by default. EF with wise use of .Include and no lazy loading is a pretty good ORM!
- tracker1 2y ago
  I switched to Dapper a long time ago, with explicit SQL queries and really haven't looked back.
bluefirebrand 2y ago
> does exactly what it says it does, with no magic I strongly believe that software we develop should feel like magic to the users The tools that we use to build them should not
BurningFrog 2y ago
> this is where I think AI for coding is now. It gets things wrong enough that I have to manually check everything The good way to do this is to write good unit tests for the code. Which we should be doing anyway!
DanielHB 2y ago
> I was especially glad of Lazy Loading, where I didn't have to load data from the database into my memory structures; the system would do that automatically. oh god, I have used Java with Hibernate a lot and once I read "Lazy Loading" I didn't even need to finish reading the post.
foxyv 2y ago
I've always found that it's easier to code something from scratch, than to review and fix someone else's code, and that's been my experience with Copilot up to this point. I'm not sure if it's better than just writing code from scratch productivity wise, but it makes coding kind of unpleasant for myself. One thing I've found about Copilot is that it introduces me to novel ways to solve problems and more obscure language features. It makes me a better coder because I'm constantly learning. But do I want to be spending my time learning or do I want to make that deadline that's coming up?
datavirtue 2y ago
I'm left wondering what AI everyone are using. I can prompt copilot and it gives me exactly what I need. Sure, if I barf out a lazy, half-baked prompt it yields a waste of time. My problem is running into it's limitations, mostly around resources. I have tried giving it larger tasks and it takes bloody forever. "Given this unstructured data, create CSV output for all platforms, with each line containing the manual, and model, ignoring the text in parenthesis." Works great except for God-awful performance and stopping half way through. I had to break out each section and paste it into the prompt and let it work on small pieces. We need to get to the next level with this, especially for paying customers. More concerning is that I see a clear pattern in smaller companies of hiring seniors and turning them loose with AI assistants instead of hiring junior devs. The prospect is attractive to nearly every stakeholder and the propensity to put off hiring "until next quarter" in light of this is a constant siren song. There is a lot of gravity pulling in this direction with the short-term thinking and distractions that are thoroughly soaked into the business world these days. Supposedly, one third of Gen Z (20-25 yrs old) are sitting at home, up from 22% in 1990. I'm one of those seniors happily putting off hiring, but I find the situation and it's wider impact on the future very unnerving.
- thegrim33 2y ago
  Well, having AI transform some data into a certain CSV format is orders of magnitude simpler and more straightforward of a programming task than what I try to use it for. A lot of the discrepancy between people's experiences is simply due to the fact there's there's a massive range of programming complexity/difficulty that people can be trying to apply AI to. If your programming is mostly lower complexity stuff, non-critical stuff, or simply defined stuff, it obviously works better. I try to use AI when I get stuck on a hard problem/algorithm, hoping that it can provide an answer/solution to unblock me. But when I'm stuck the problem I'm facing is so complicated that there's no chance at all that AI is actually going to be able to help me with it. I see absolutely no point in using AI when I already know how to solve a problem, I just solve it. I only turn to it when I need help, and it can never help me.
specialist 2y ago
Object-Relational Mappers purport to mitigate the impedance mismatch between object-oriented and relational data structures. For your analogy to hold, what is the impedance mismatch between programming and Copilot?

nercury 2y ago

Pardon me for the tangent (just a general comment not directed to OP). What I have learned over the years is that the only way to properly use ORM is as a fancy query tool. Build the query, fetch/update data, MOVE THE DATA to separate business objects. Don't leave ORM entities shared across the sea of objects! Phew, thanks, I got that off my chest.

rafaelmn 2y ago
That doesn't really help you with EF because there's plenty of stuff shared at context level. So depending on the order of queries in the context the same query can return different data. I hate EF and everything it stands for. :)
- nercury 2y ago
  Yeah, in a web app, one context per request. In desktop app... I have never used EF there.
noduerme 2y ago
adding an off the shelf ORM layer creates so much more opacity and tech debt than writing queries I don't understand why anyone would willingly put one into their stack. Sure, they're neat although I don't even know if they save time. There's something very satisfying about well-crafted queries. And is it ever really well crafted if you can't tweak them to improve their their execution plan? I've never had a client or boss who asked to use an ORM framework. I suspect it's something people think looks cool - treating SQL as OOP - until they run into a problem it can't solve. [edit] for instance, I have a case where I use a few dozen custom queries on timers to trawl through massive live data and reduce it into a separate analytics DB. Using everything from window functions to cron timers to janky PHP code that just slams results from separate DBs together to provide relatively accurate real-time results. At the end from that drastically reduced set in the analytics DB... sure, I'm happy to let the client summarize whatever they want with Metabase. But those things just couldn't be done with an ORM, and why would I want to?
- bad_username 2y ago
  For me the biggest reason is automated database initialization and migration. After defining or updating the ORM model, I don't have to worry about manually CREATing and ALTERing tables as the model evolves. This is compatible with the OC suggestion of using ORMs as a "fancy query builder" and nothing more, which I strongly support.
  - noduerme 2y ago
    I'm not sure if you're talking about creating and altering model tables or if you mean ORMs provide safety in case underlying tables are modified. I'd argue that well-built queries should be resistant to alteration of the underlying tables, and that views and functions and stored procedures already exist to both red flag breaking changes and also to combine and reduce whatever you need without relying on third party code in another language layer to do the lifting.
  - blksv 2y ago
    Doesn't it also mean that any non-trivial migration (e.g. which requires data transformation or which needs to be structured to minimize locking) has to be defined elsewhere, thus leaving you with two different sources for migrations, plus some (ad-hoc) means to coordinate the two? (I would say that it is conceptually perverse for a client of a system to have authority over it. Specifically, for a database client to define its schema.)
marcus_holmes 2y ago
Agree completely, as does most of the Go community :) Newbie gophers are regularly told to learn some SQL and stop trying to rebuild ActiveRecord in Go ;) But in .Net, EF is still the most common way of accessing data (I have heard, because I stopped using it over a decade ago).
- deleted 2y ago
  [deleted]
- lomase 2y ago
  EF is the common way of saving data.
arrowsmith 2y ago
I wouldn't have believed you until I moved from ActiveRecord (Rails's ORM) to Ecto (Elixir/Phoenix's data mapping library which is decidedly not an ORM.) It's a million times better and I'm never going back.
- cultofmetatron 2y ago
  same, I wish more libraries would go the ecto design route. my ecto queries map pretty close to 1:1 with the sql counterpart. no guessing what the output is going to look like. I spend my time debugging the query and not trying to get the orm to output he query I want.
  - arrowsmith 2y ago
    Yeah, I hear some people say that they find Ecto.Query confusing, and I think it's because they never learned SQL properly. That's understandable because it's possible to use something like ActiveRecord for years without ever learning to write even a simple SQL query. But if you have a good grasp of SQL then Ecto.Query is trivial to learn - it's basically just SQL in Elixir syntax.
    - cultofmetatron 2y ago
      > it's basically just SQL in Elixir syntax. its sql in elixir syntax with a bunch of QOL improvements. for one thing, I can seperate my subqueries into separate variables ``` sub_q = from(l in Like) |> where([l], l.user_id == ^user_id) |> select([l], %{ user_id: l.user_id, likes_count: count(l.id) }) |> group_by([l], l.user_id) main_query = from(u in User) |> join(:left, [u], likes_count in ^subquery(sub_q), on: likes_count.user_id == u.id, as: :likes_count) |> select([u, likes_count: l], %{ name: u.name, likes: l.likes_count, }) |> where([u], u.id == ^user_id) user = main_query |> Repo.one() ``` Being able to think directly in sql lets you perform optimal queries once you understand sql. and imho, this much cleaner than tha equivalen sql to write. it also takes care of input sanatization and bindings.
  - freedomben 2y ago
specialist 2y ago
> use ORM is as a fancy query tool As an alternative to query-by-example (QBE)? https://en.wikipedia.org/wiki/Query_by_Example https://en.wikipedia.org/wiki/Query_by_Example

kaba0 2y ago

> and started learning Go. Which does exactly what it says it does, with no magic Too little abstraction is just as bad as too much.

alrs 2y ago
Assembly is too little abstraction. Go is not.
- neonsunset 2y ago
  It is. Oh, and also, Go managed to screw up even the assembly, inventing portable but actually not dialect that uses ugly bits of AT&T syntax, custom operator precedence and in practice is non-portable, forcing you to mix Go-only mnemonics (which might even collide with opcode names on certain platforms), supported opcodes of target platform, and BYTE literals for opcodes it doesn't support, making a lot of your preliminary (N)ASM knowledge useless. Isn't that magnificent? Gee, I wonder if there's a better way to do so that is not such a lazy job. But doing it properly, like .NET does, is supposedly too much effort!
  - alrs 2y ago
    It would be great if C# could be discussed as a language on its merits, but Microsoft has been a terrible steward. It's too bad.
    - neonsunset 2y ago
      So you are saying it's even worse than suing anyone over using the language like a certain Java-related company or laying off people off the core language team like a certain Dart-related company?
jimbokun 2y ago
The amount of abstraction available in Go is just about right. It gives you higher level constructs, while still being reasonably straightforward to predict memory and CPU performance and behavior.

smokel 2y ago

A key difference between database mapping and interactive AI tools is the position of the user. I would not be enthusiastic about a system where I receive database query results for review, before delivering them to an end user somewhere on this planet. However, I am more than happy to get some extra help in communicating code from my brain to a compiler.

neonsunset 2y ago

And it’s by far the best one now that all the issues that made old EF unsound were solved in EF Core. Good developers know to appreciate that and wouldn’t want to touch Go ecosystem afterwards with a 10 feet pole.

LandR 2y ago

Well, this month we had to debug an issue where EF was NOT populating fields on classes from the db, that it definitely should have been! So it still seems flakey. I've never worked a single job that chose EF that didn't end up regretting it. Either from it being unreliable, migration hell or awful performance. "It allows you to treat your database like an in-memory enumerable" Then devs go and do exactly that and wonder why performance is so terrible... I hate EF.

neonsunset 2y ago
Which version?
- LandR 2y ago
  We are currently on the latest. We had an issue last week where we had an obect like public class Foo { public List<Bar> Bars { get; set; } } We'd query for some Foos, like: await _dbContext.Foos.ToListAsync(); and some amount of them would have Bars be an empty list where it should definitely be populated from the db. And it wasn't even consistent, sometimes it would populate thousands, sometimes it would populate a handful and then just stop populating Bars. No errors, no exceptions, just empty lists where we'd expect data. And so often we have to debug and see what SQL its actually generating, then spend time trying to get it to generate reasonable sql, when if we were using sprocs we could just write the damn sql quicker. Another issue we have is the _EFMIgratoinsHistory table. Sometimes we will deploy and get a load of migration errors, as it tries to run migrations its already ran... SO they all fail and then the API doesn't come back up... The fix ? TUrn it off and on again and it stops trying to re-run migrations its already ran!
  - neonsunset 2y ago
    EF Core 8? Inconsistent behavior is not expected. Assuming you haven't missed to add an .Include[0], please consider submitting an issue(s) to https://github.com/dotnet/efcore https://github.com/dotnet/efcore [0] https://learn.microsoft.com/en-us/ef/core/querying/related-data/eager https://learn.microsoft.com/en-us/ef/core/querying/related-d...

kamaal 2y ago

>>It gets things wrong enough that I have to manually check everything it does and correct it, to the point where I might as well just do it myself in the first place. I have had personal experience with this. And seen others telling me as well. These AI things often suggest wrong code, or even with bugs. If you begin your work by assuming AI is suggesting the correct code you can go hours, to even days debugging things in the wrong place. Secondly when you do arrive at a place where you find the bug in the AI generated code, it can't seem to fix or even modify it, because it misses context in which the which itself generated at the first place. Thirdly the AI itself can interpret your questions in a way you didn't mean. As of now AI generated code is not for serious work of any kind. My guess a whole new paradigm of programming is needed, where you will more or less talk to AI in a programming language itself, some what like lisp. I mean a proper programming language at a very abstract level, which can be interpreted in only one possible meaning, and hence not subject to interpretation.

cess11 2y ago
"My guess a whole new paradigm of programming is needed, where you will more or less talk to AI in a programming language itself, some what like lisp. I mean a proper programming language at a very abstract level, which can be interpreted in only one possible meaning, and hence not subject to interpretation." Code generation is quite old though, and also quite common, also outside the Lisp-family. When doing non-trivial systems development in Java you tend to use it a lot, especially with XML as an intermediary, abstracted language.

Quothling 2y ago

> [0] Entity Framework has moved on a lot since then, and apparently now can be trusted to lazily load data To some degree. If you're using it for anything serious you're still going to help it along a lot. It's rather easy to do so, however, and I certainly wouldn't consider writing your own code as fast or easy as simply telling EF how you want it to do certain things. I'm not an overall fan of EF. I especially dislike how it's model builder does not share interoperability with other .Net libraries which also use it. I also don't really like the magic .Net does behind the scenes. EF as a whole has been one of the better ORMs for any language since .net core. I'd still personally much prefer something like Rust's diesel, but whenever I have to work with C# I tend to also use EF.

Foobar8568 2y ago
Diesel is not an ORM and a typical rust library...
- kevthecoder 2y ago
  The strapline seems to suggest it is an ORM (I've not used Diesel yet): >Diesel: A safe, extensible ORM and Query Builder for Rust https://github.com/diesel-rs/diesel https://github.com/diesel-rs/diesel
to11mtm 2y ago
You might want to try Linq2Db, it is much closer to Diesel in how it works (More SQL DSL with parameter+reader mapper, less Unit-of-work ORM). FWIW, it can actually work 'on top' of an Existing EF Core context+mappings (i.e. if you have an existing project and want to migrate, or just need the better feature-set for a specific case.) or you can get pretty close to 'yolo by convention' depending on case. In general though it's a lot less ceremony to start messing around.

Foobar8568 2y ago

From what I remember, lazy loading wasn't part of EF for a long while and even longer for navigational properties. I am not even sure if it was part of EF4.

nurumaik 2y ago

>It gets things wrong enough that I have to manually check everything it does and correct it Thing is, reading code is way faster than writing code

deely3 2y ago
Huh, for me its always vice versa. When I'm not sure in the someones code I have to double or triple check it be sure that I understand it correctly and to verify that there no somehow hidden missed steps or side effects.

BaculumMeumEst 2y ago

Even more important than the question of productivity is that this turns a joyous activity into a depressing probabilistic shitshow where you describe what you're trying to do and hope for the best. Instead of feeling engaged and challenged, you're just annoyed and frustrated. No thanks!

whywhywhywhy 2y ago

I feel pre November “dev day” 90% of the time I could trust GPT4 output to just work but post downgrades the increased amount of times I’ve copy and pasted then seen the error and realized there’s unfinished placeholder stuff, straight up parts not done or previous code removed that was important. Just means I now spend a lot of time rewriting it which I could have just done in the first place but now I’ve wasted time asking GPT too.

naasking 2y ago

> Long analogy short, this is where I think AI for coding is now. It gets things wrong enough that I have to manually check everything it does and correct it, to the point where I might as well just do it myself in the first place. Even if that were true, reading code is reasonably faster than typing it out and then reading it again to check it.

dmix 2y ago

> this is where I think AI for coding is now. It gets things wrong enough that I have to manually check everything This might be dependant on the programming language, some languages are way more popular and have way more questions on StackOverflow and Reddit and repos on github, so the answers will be better. When I use copilot for JS it's right 90% of the time. And where it's 'wrong' it's usually just stuff it skipped over because it didnt have proper context.

rspeele 2y ago

Lazy loading was a mistake in EF. A lot of apps had awful performance due to lazy loading properties in a foreach loop creating N+1 queries to the database. It would be fine in dev with 50-100 rows and a localhost SQL and blow up in prod with 1000s of rows and a separate Azure SQL. Also if you relied on lazy loading properties after the DbContext had been disposed (after the using() block) you were out of luck. With old EF we would turn off lazy loading to make sure devs always got an exception if they hadn’t used .Include() to bring the related entities back in their initial query. Querying the database should always be explicit not lurking behind property getters. Fortunately with EF core MS realized this and it’s off by default. EF with wise use of .Include and no lazy loading is a pretty good ORM!

tracker1 2y ago
I switched to Dapper a long time ago, with explicit SQL queries and really haven't looked back.

bluefirebrand 2y ago

> does exactly what it says it does, with no magic I strongly believe that software we develop should feel like magic to the users The tools that we use to build them should not

BurningFrog 2y ago

> this is where I think AI for coding is now. It gets things wrong enough that I have to manually check everything The good way to do this is to write good unit tests for the code. Which we should be doing anyway!

DanielHB 2y ago

> I was especially glad of Lazy Loading, where I didn't have to load data from the database into my memory structures; the system would do that automatically. oh god, I have used Java with Hibernate a lot and once I read "Lazy Loading" I didn't even need to finish reading the post.

foxyv 2y ago

I've always found that it's easier to code something from scratch, than to review and fix someone else's code, and that's been my experience with Copilot up to this point. I'm not sure if it's better than just writing code from scratch productivity wise, but it makes coding kind of unpleasant for myself. One thing I've found about Copilot is that it introduces me to novel ways to solve problems and more obscure language features. It makes me a better coder because I'm constantly learning. But do I want to be spending my time learning or do I want to make that deadline that's coming up?

datavirtue 2y ago

I'm left wondering what AI everyone are using. I can prompt copilot and it gives me exactly what I need. Sure, if I barf out a lazy, half-baked prompt it yields a waste of time. My problem is running into it's limitations, mostly around resources. I have tried giving it larger tasks and it takes bloody forever. "Given this unstructured data, create CSV output for all platforms, with each line containing the manual, and model, ignoring the text in parenthesis." Works great except for God-awful performance and stopping half way through. I had to break out each section and paste it into the prompt and let it work on small pieces. We need to get to the next level with this, especially for paying customers. More concerning is that I see a clear pattern in smaller companies of hiring seniors and turning them loose with AI assistants instead of hiring junior devs. The prospect is attractive to nearly every stakeholder and the propensity to put off hiring "until next quarter" in light of this is a constant siren song. There is a lot of gravity pulling in this direction with the short-term thinking and distractions that are thoroughly soaked into the business world these days. Supposedly, one third of Gen Z (20-25 yrs old) are sitting at home, up from 22% in 1990. I'm one of those seniors happily putting off hiring, but I find the situation and it's wider impact on the future very unnerving.

thegrim33 2y ago
Well, having AI transform some data into a certain CSV format is orders of magnitude simpler and more straightforward of a programming task than what I try to use it for. A lot of the discrepancy between people's experiences is simply due to the fact there's there's a massive range of programming complexity/difficulty that people can be trying to apply AI to. If your programming is mostly lower complexity stuff, non-critical stuff, or simply defined stuff, it obviously works better. I try to use AI when I get stuck on a hard problem/algorithm, hoping that it can provide an answer/solution to unblock me. But when I'm stuck the problem I'm facing is so complicated that there's no chance at all that AI is actually going to be able to help me with it. I see absolutely no point in using AI when I already know how to solve a problem, I just solve it. I only turn to it when I need help, and it can never help me.

specialist 2y ago

Object-Relational Mappers purport to mitigate the impedance mismatch between object-oriented and relational data structures. For your analogy to hold, what is the impedance mismatch between programming and Copilot?