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

RRULE type cannot be stored #20

Open
Natureshadow opened this issue Jul 24, 2024 · 1 comment
Open

RRULE type cannot be stored #20

Natureshadow opened this issue Jul 24, 2024 · 1 comment

Comments

@Natureshadow
Copy link

Storing RRULEs in their compiled form leads to segmentation faults upon retrieval. This happens due to the icalrecurrencetype having an icaltimetype field, which in turn has a pointer to icaltimezone:

https://github.com/Marketcircle/libical/blob/4272d2f81851a37bb08d9ac977a2f672b54e2a20/src/libical/icaltime.h#L136

For obvious reasons, structs with pointers cannot be safely stored in Postgres heap files.

I don't know of any way to prevent a type from being stored, but maybe this should be documented with a huge red flag.

@thomastthai
Copy link

thomastthai commented Oct 10, 2024

What about serializing and deserializing to string, or using a custom storage format for RRULEs to address the struct with pointer issues, like:

  • Protocol Buffers (Protobuf)
  • FlatBuffers
  • Cap'n Proto

For example, some highlights (thanks AI) for how Protocol Buffers provides a workaround:

  • Schema Definition: You define the structure of icalrecurrencetype in a .proto file without using pointers. Instead, you'll replace the icaltimezone pointer with a suitable time zone identifier (like a string representing the time zone name or ID).
  • Serialization: When you serialize the structure, Protocol Buffers generates a compact binary format that does not include any pointers. This format is safe for storage in a PostgreSQL database. The binary data generated from this serialization can then be stored in a bytea field in PostgreSQL, safely avoiding the issues related to storing memory pointers, e.g., storing timezone_id as a string "America/New_York" instead of a pointer.
  • Deserialization: When you retrieve the binary data from the database, Protobuf will deserialize it back into the original structure, ensuring that the timezone_id is properly retrieved as a string.
  • Time Zone Rehydration: After deserialization, you can use the timezone_id (retrieved from the serialized data) to look up the appropriate icaltimezone object in memory (if needed). This prevents any issues with dangling pointers or segmentation faults, as the time zone data is always dynamically reloaded.

Storing the RRULEs as a string is the simplest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants