Refactor item_id retrieval logic in operation logging

[Robin-Rhee]

Hi,
Nick,

This PR was originated from a resolution to a Q&A discussion in the docker_open5gs repo.

1. Refactor item_id assignment to avoid using 'or' expression and ensure proper handling of item_id.

The "or" expression means by the following logic

if bool(item_id) is True:
    return item_id
else:
    return generated_id

So if the item_id is 0, it would be treated as false, which causes the item_id to get the value of generated_id (None).
This triggers the mysql to return error because the item_id should be non-null as defined in the schema.

2. Change the sequence of getattr() and session.flush()

The item_id should invoke getattr() after session flush, thereafter the beforehand APN insertion can be presented to the DB.
In this way, the getattr function can actually get the apn_id of an existent APN record.

[osmith42]

Looking at how this works, users can send their own ID to the API call for adding an APN and they can choose 0 as ID. (I was a bit surprised by this, since auto-incrementing integers in databases start at 1 and docs/provisioning.md talks about using APNs with IDs 1 and 2.)

So this looks good to me, I would only adjust the comment to explain why or is not used here (or remove the comment line entirely).

Thanks for sending this fix!

[Robin-Rhee]

Looking at how this works, users can send their own ID to the API call for adding an APN and they can choose 0 as ID. (I was a bit surprised by this, since auto-incrementing integers in databases start at 1 and docs/provisioning.md talks about using APNs with IDs 1 and 2.)

So this looks good to me, I would only adjust the comment to explain why or is not used here (or remove the comment line entirely).

Thanks for sending this fix!

Thank you very much, Oliver !!
Just made the fine tune in line with your request.

[osmith42]

Thanks again!