API: /inventory/create accepted arguments

Stragus

At the moment, there are some lot values which can't be specified when creating a lot: personal_note, public_note, bulk_qty, etc. Instead, they have to be specified by a separate /inventory/update query, which requires the previously created lot's lot_id.

So, we have to first create a lot, get the lot_id from the reply, and send an update with the full data.

I'm finding that system a little awkward when aiming for absolute robustness. Let's suppose we never get the reply to the /inventory/create query (poor internet connection, a power cut, whatever), it requires quite a bit of bookkeeping to later locate the partially specified lot and finish the job.

Could we just get an /inventory/create as complete as /inventory/update?

Thank you!

Lawrence

Possibly in the future, but not immediately. The idea is to reduce code duplication and the chance of bugs on my side. Create takes the minimum required to create a lot.

Stragus

Darn, all right then. That's going to be quite a bit of extra code for absolute robustness (including power cuts).

Teup

I'm finding that system a little awkward when aiming for absolute robustness. Let's suppose we never get the reply to the /inventory/create query (poor internet connection, a power cut, whatever), it requires quite a bit of bookkeeping to later locate the partially specified lot and finish the job.

Hmm I don't know about that, I could be wrong, but I think that your code is executed so instantaneously that the odds for it to complete the first task and then hang on the second are very slim. Internet is sometimes not responsive but once it is and you fire 2 requests I think it should be fine.

You could however build something into your code to deal with this. Once the lot id is retrieved and the second operation is attemted, you can store the lot id in memory, or a data file, execute the second operation, then remove it again. If something goes wrong and the procedure hasn't reached the end, the lot id will still be around and your program can have it deleted from your inventory.

Stragus

@Teup The "create" and the "update" queries can't be executed simultaneously, as the second has to wait the server's reply from the first query. It's quite possible to send the first query and never get a reply from the server, and we therefore have to fetch the whole inventory again to check if the lot was created or not (no problem there).

If we have lots that have been created but not yet updated, then these lots have to be later located in the inventory to perform the appropriate updates (define fields comments, remarks, etc.). And, in the meantime, the lots themselves may have changed from incoming orders. All this can still be resolved gracefully, the lots can be located, *only* if multiple lots for identical items (BOID, color and condition) are forbidden.

Really, this gets messy.

Maybe I just don't know how to write non-robust software (my usual field is high performance computing software for clusters ).

Teup

All this can still be resolved gracefully, the lots can be located, *only* if multiple lots for identical items (BOID, color and condition) are forbidden.

Well, if I understood you correctly, you said the first operation of creating returns the lot id. Once you have that and you store that, you can later on delete it if the second update operation failed, right? So once your program is run for the second time it'll go, 'hey, I see some unfinished lot ids, let's go delete them'. True, people could go and buy it in the meantime, but when the shit hits the fan you're probably fast enough to reboot, reset your internet, and run your software again.

But then.. maybe there's a possible scernario where it is created but the lot id isn't yet returned properly. Then.. yeah, that sucks

Obviously you're a way better programmer than I am, but anyway that's how I'd do it, with my toothpaste-and-rubber-bands programming skills

Stragus

But then.. maybe there's a possible scernario where it is created but the lot id isn't yet returned properly. Then.. yeah, that sucks

Correct, this is the scenario that's a little problematic. You send the "create" query to the server, and before you can receive the "lot id", a shaky internet/power cut/kernel panic/earthquake/alien invasion occurs. If identical lots are forbidden, locating the lot is still possible from ID/color/condition, I guess I'll have to enforce that condition for anyone using the software.

Otherwise, the issue could be mitigated by fully creating each item, one at a time... but then you lose HTTP 1.1 pipelining plus the whole TCP & SSL handshake has to be renegotiated for every item (bad stuff! ).