Which one is easier to develop and work with (which saves the most time)? Which one would you go for? The name of the API represents its true purpose in this case by the way, createOrUpdate creates or updates the passed in meeting and create just creates the meeting. I will be the only one working on this project for now, although obviously, I would like others to work on it with me eventually.

  • Joe@kbin.social
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    I would have 2 functions: createMeeting and updateMeeting

    No point having one function do two different things, especially if one of them isn’t even hinted at by the function name

  • macgregor@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    Many databases or database clients have an “upsert” operation which is exactly this. Create or update this entity. If the DB supports it you can save an explicit lookup giving minor performance and code cleanliness improvements in application but might shift that performance cost to the DB (had to rollback a prod change not too long ago because someone switched to a PG upsert and it caused average CPU to rise, haven’t gotten a chance to investigate why yet, something about indexes probably).

    Anyway, I tend to start with just explicit create and update methods and add an “upsert” abstraction if I find myself sprinkling lots of checks around making code messy. So I would go for “createOrUpdateFoo” in that case.

  • fabian@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 year ago

    Well, it makes the client-side calls a bit simpler if you don’t distinguish create and update via POST/PUT, so at the server-side you have a single POST endpoint which does the upsert, but there it would be sensible to dispatch to separate methods for insert and update each.

  • TheButtonJustSpins@infosec.pub
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Is there any reason that the caller wouldn’t know if the meeting they’re holding has been created or not? I’d keep it simple by keeping them separate unless there’s a compelling reason to meld them.

    • JokersPistol@programming.devOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      The only thing I can think of is when the user edits meetings en masse – say they’re rescheduling their whole day and are simultaneously creating and updating the timing of blocks. That probably will be functionality I’ll want to implement (allowing users to enter “edit mode” for their schedule).

      That’s a good question though, other than that case it wouldn’t be relevant. Plus, I probably would implement a createOrUpdateMeetings() API rather than createOrUpdateMeeting should that occur. Since Create and Update are both relatively simple APIs to implement, I think I’ll stick with those for now and possibly shift over to createOrUpdate if the need comes up. Thanks for the insight!

      • sbv@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        If the function is doing input validation, it might be cleaner to have a single code path for both creation and update. Especially if you eventually assemble an SQL statement that is INSERT OR UPDATE.

  • none@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Even if I had a createOrUpdate function I would still have an explicit create function so that I can have a permission model that allows for creating but not updating. For meetings maybe it doesn’t matter, but I worked in a financial setting where a very unfortunate design decision was made early on in the development of a ledger where it was crucial that transactions couldn’t be updated, but the database was designed in such a way that there wasn’t a way to give the application permission to create new transactions without also allowing it to update existing ones. Required quite a bit of work to build around this limitation and have a way to prove that a series of transactions hadn’t been altered.