Today my day was spent getting bent over by ASP.NET (Core) and for some of it I for some reason for the fucking life of me could not get to work.

And even though I didn’t end the day on a good note in the project, I DID make some small progress, the problem I ran across was that I wasn’t inserting the ID into the database, but the real problem is that I tried to have the database generate the ID itself and increment it, but that didn’t work out so I’m stuck and I have no clue what I should do and I tried to manually set it too for one case but even that resulted in error, so 🤷🏻‍♂️

Feeling very intimidated while doing this. I’m hoping I’ll be able to write code that can actually scale and handle production.

That’s been my day.

  • 3
    Share the schema
  • 1
    @SortOfTested what do you mean
  • 3
    If you were to do a CREATE TABLE what would it look like?
  • 2
    What spongey said, right click in whatever tool you have and look for something to the effect of "script table"
  • 1
    @spongessuck oh uh

    Id, FirstName, LastName, Email, Gender, Major

    (gender and major are both enums)

    But the only problem is the ID
  • 2
    We're actually interested in the key specification the database returns. That'll show where the problem is.
  • 0
    Either you forgot to tell efcore to value generate on add for the id column, forgot to set the id column as a key, forgot to call SaveChanges on the dbcontext or something else even.
    Just guesswork at this point
  • 0
    @SortOfTested you mean like how C# represented it as a data type? if so int, And the SQLite DB Browser says the Schema for ID is “INTEGER NOT NULL”

    @jespersh I did include the SaveChanges method, the DatabaseGenerated Attribute (with its parameter DatabaseGeneratedOption.Identify) and the Key attribute, and no dice
  • 4
    I don't work from code first scenarios in most cases. The better approach is to create the tables in the DB, then use EF scaffold to generate the contexts. Then you can build migrations and updates, while also getting the best performance and no guesswork.

  • 0
    @SortOfTested I’ll try that tomorrow.

    I just wish I had something better I could learn from, Ive tried a few books, video playlists, documentation, it just all feels so unorganized and messy and like there’s not really a good way to start, and there’s only ever really resources for MVC which I do plan to cover but I was wanting to tackle razor pages since the project I’m making isn’t too big.

    Also thanks for the help/advice
  • 1
    This feels pretty typical to EF and similar frameworks. It "just works, don't worry about it", but once you run into a snag it's tricky to troubleshoot because "it should just work, don't worry about it".

    Agree with trying concrete sql to initialize the db and tables. Then you get rid of EF as a dependency at the db layer.
  • 2
    @ltlian I did that with the last project I did but I was trying to rely more on EF this time around to help me just improve with it and prep for possible professional scenarios where I’d have to but idk probably sounds stupid
  • 2
    Using EF is absolutely fine, but I think many prefer to handle table setup and such themselves for the reasons mentioned. I've had my share of projects where we spent more time trying to make the framework do the sql command we needed than simply writing them ourselves.
  • 1
    EF is pretty good but the core version was missing some functions and had some bugs that the the framework version did not.

    Problem with ID’s that are DB generated is that either ef needs the id to work so you could try to use a guid instead, that way ef can create it without having to touch the db.

    And yes, code first is a nice concept but I also had major problems since if you do end up with a problem its not easy to troubleshoot.

    I always builds the db my self.

    And frankly, I usually do avoid all inclusive frameworks as ef.

    Yes they do lessen the code in most cases, but if the tables get to complex or very large you have to work around a lot of issues as ef can have a hard time to find the right way to construct the queries.

    Found that the hard way a few times when performance tanked when the tables grew.
  • 0
    Or use dapper unless EF has to be used cause of team..
Add Comment