Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider reworking batch operations info #421

Closed
DifferentialOrange opened this issue Feb 14, 2024 · 2 comments
Closed

Consider reworking batch operations info #421

DifferentialOrange opened this issue Feb 14, 2024 · 2 comments
Labels
question Further information is requested

Comments

@DifferentialOrange
Copy link
Member

*_many operations errors have operation_data field to help identify which exact records had errors. This info is used to automatize these processes: for example, in tt-ee tt crud import.

But matching input and error output is complicated:

  • for *_object_many, operation data will be a tuple in the most cases, so one must either flatten the object or unflatten the tuple manually;
  • operation data will have bucket_id filled in the most cases, so it needs to be manually stripped;
  • empty maps may transform to empty arrays and vice versa while working with net.box.

Matching input and success output is also can be complicated, if triggers or sequences are used on the storage.

On the other hand, if response had the structure similar to the following one:

crud.insert_many({{1, box.NULL, "val"}, {0, box.NULL, "val"}, {3, box.NULL, "val"}})
- rows:
    - id: 1 
      data: [1, 123, "val"]
- errors:
   - id: 2
     data: [0, box.NULL, "val"]
     err: duplicate_key
   - id: 3
     data: [3, box.NULL, "val"]
     err: rolled back

with explicit "input row N has been successfully inserted, result after inserting is X" and "input row M has failed due to the following reason", it would simplify things like tt crud import.

@DifferentialOrange DifferentialOrange added the question Further information is requested label Feb 14, 2024
@DifferentialOrange
Copy link
Member Author

Such rework is likely to break compatibility and drop the performance, so we should decide carefully.

@DifferentialOrange
Copy link
Member Author

Duplicate of #396

@DifferentialOrange DifferentialOrange marked this as a duplicate of #396 Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant