gd_delete(3)

💖 gd_delete — bestie, we're deleting a field from a Dirfile 💖

okay so this is a GETDATA manual page, section 3 (library calls, iykyk). It's gd_delete, and it's exactly what it sounds like: you point at a field in a Dirfile and the library goes ✨ poof ✨. Let's get into it.

✨ SYNOPSIS ✨

#include <getdata.h>

int gd_delete(DIRFILE *dirfile, const char *field_code, unsigned int flags);

🌸 DESCRIPTION 🌸

The gd_delete() function attempts to delete the field or alias specified by field_code from the dirfile specified by dirfile. Note the word attempts — this girl can fail, and we'll get to that.

Real talk: field_code should not contain a representation suffix. Just don't do it.

The flags argument is the vibe-setter for how the deletion goes down. It can be:

• zero — for the default behaviour, no notes, just do the thing
• or one or more of the flags below, bitwise or'd together

Here's the flag menu, bestie:

• GD_DEL_DATA — if the field you're deleting is a RAW field, this also deletes the binary data file that's associated with it. BUT — and this is the important part — if field_code specified a RAW field and you did not pass this flag, the field still gets deleted, the binary file just gets left untouched. The file is still there. Living its life. Alone. 🙈
• GD_DEL_DEREF — if the field being deleted is a CONST or CARRAY field that's used as a parameter in the specification of other fields, this resolves those other fields' dependence on the deleted field by replacing instances of field_code in their field specifications with the value of the scalar field. Basically it's doing the substitution homework for you. 🎀
• GD_DEL_FORCE — delete the indicated entry even if it's used in the specification of other fields, either as an input for a derived vector field or as a scalar parameter in a field specification, or if it has aliases pointing to it. Chaotic. Iconic. Destructive. Slay, honestly. 💅
• GD_DEL_META — if the field you're deleting has metafields attached to it, this attempts to delete those too. And if the field has metafields and you did not pass this flag, the call will fail with the GD_E_DELETE error. So like, decide. 🫶

😭 RETURN VALUE 😭

On successful deletion, zero is returned. On error, a negative-valued error code is returned. Possible error codes, and what each one is trying to tell you:

• GD_E_ACCMODE — the specified dirfile was opened read-only. Can't delete in read-only, babe.
• GD_E_ALLOC — the library was unable to allocate memory. 😵
• GD_E_BAD_CODE — the field specified by field_code was not found in the database. It's not there. It never was. 💀
• GD_E_BAD_DIRFILE — the supplied dirfile was invalid.
• GD_E_DELETE — the attempt to delete the field failed. Either it is used in the specification of other fields and GD_DEL_FORCE or GD_DEL_DEREF was not specified, or it has metafields and GD_DEL_META was not specified.
• GD_E_INTERNAL_ERROR — an internal error occurred in the library while trying to perform the task. This indicates a bug in the library. Please report the incident to the GetData developers. Not you, them. 🐛
• GD_E_IO — an error occurred while trying to close or delete the binary file associated with a RAW field.
• GD_E_PROTECTED — the metadata of the fragment containing the field was protected from change. Or, the deletion of the binary data file associated with a RAW field was attempted and the data of the fragment was protected. Hands off, it's protected. 🛡️
• GD_E_UNKNOWN_ENCODING — the GD_DEL_DATA flag was given but the encoding scheme of the indicated format specification fragment is not known to the library. As a result, the library was unable to delete the binary file associated with a RAW field.
• GD_E_UNSUPPORTED — the GD_DEL_DATA flag was given but the encoding scheme of the indicated format specification fragment does not support deleting the binary file associated with a RAW field.

The error code is also stored in the DIRFILE object and may be retrieved after this function returns by calling gd_error(3). A descriptive error string for the error may be obtained by calling gd_error_string(3). So you're never left guessing what went wrong, fr fr.

📜 HISTORY 📜

• The function dirfile_delete() appeared in GetData-0.5.0.
• In GetData-0.7.0, this function was renamed to gd_delete().
• In all GetData-0.8.x releases, passing an alias name to this function would delete the target of the alias. To delete an alias itself, a separate function, gd_delete_alias() was available.
• In GetData-0.9.0, gd_delete_alias() was removed.
• In GetData-0.10.0, the error return from this function changed from -1 to a negative-valued error code.

👀 SEE ALSO 👀

gd_close(3), gd_error(3), gd_error_string(3), gd_metaflush(3), gd_open(3)

and that's the whole page, bestie 🦋 This was Version 0.10.0, dated 25 December 2016 — a lil Christmas gift from the GetData girlies 🎁✨ go forth and delete responsibly, and pls pass GD_DEL_FORCE with the respect it deserves 💖