-
Notifications
You must be signed in to change notification settings - Fork 5
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
feat: Add support for serializing/deserializing auto-generated key-value pairs in the new IR format. #127
feat: Add support for serializing/deserializing auto-generated key-value pairs in the new IR format. #127
Changes from 2 commits
49e1313
adac44f
1aed4f8
2785253
35c9fc4
36e4cdb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,7 +2,7 @@ from __future__ import annotations | |
|
||
from datetime import tzinfo | ||
from types import TracebackType | ||
from typing import Any, Dict, IO, List, Optional, Type | ||
from typing import Any, Dict, IO, List, Optional, Tuple, Type | ||
|
||
from clp_ffi_py.wildcard_query import WildcardQuery | ||
|
||
|
@@ -86,8 +86,8 @@ class FourByteDeserializer: | |
) -> Optional[LogEvent]: ... | ||
|
||
class KeyValuePairLogEvent: | ||
def __init__(self, dictionary: Dict[Any, Any]): ... | ||
def to_dict(self) -> Dict[Any, Any]: ... | ||
def __init__(self, auto_gen_kv_pairs: Dict[Any, Any], user_gen_kv_pairs: Dict[Any, Any]): ... | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Shall we swap the order of (That said, I can see any generic developers might not need to call this constructor.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This constructor is mainly for testing purpose; we usually construct There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thought a little more. I feel like we shouldn't allow optional input even in |
||
def to_dict(self) -> Tuple[Dict[Any, Any], Dict[Any, Any]]: ... | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That whether kv-pairs are auto-generated might not matter to all developers. Can we also provide a helper to return a single dict? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hmmm, my understanding is this should be the low level API, so we should return whatever given on the serialization end.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, i was proposing that we can simply merge the two dicts into one. That there can be potential key conflicts, though rare, is valid concern. If we are to keep returning a tuple, having the user-kv-pairs as the first element might be more flexible to developers. e.g., they can write
to only get the user inserted pairs, if they don't care about the auto generated ones. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hmmm, the current ordering strictly follows the underlying ffi core APIs. |
||
|
||
class Serializer: | ||
def __init__(self, output_stream: IO[bytes], buffer_size_limit: int = 65536): ... | ||
|
@@ -98,7 +98,9 @@ class Serializer: | |
exc_value: Optional[BaseException], | ||
traceback: Optional[TracebackType], | ||
) -> None: ... | ||
def serialize_log_event_from_msgpack_map(self, msgpack_map: bytes) -> int: ... | ||
def serialize_log_event_from_msgpack_map( | ||
self, auto_gen_msgpack_map: bytes, user_gen_msgpack_map: bytes | ||
) -> int: ... | ||
def get_num_bytes_serialized(self) -> int: ... | ||
def flush(self) -> None: ... | ||
def close(self) -> None: ... | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -85,11 +85,14 @@ class PyKeyValuePairLogEvent { | |
} | ||
|
||
/** | ||
* Converts the underlying key-value pair log event into a Python dictionary. | ||
* @return A new reference to the created dictionary on success. | ||
* Converts the underlying key-value pair log event into Python dictionaries. | ||
* @return A new reference to a Python tuple containing a pair of Python dictionaries on | ||
* success: | ||
* - A Python dictionary for auto-generated key-value pairs. | ||
* - A Python dictionary for user-generated key-value pairs. | ||
* @return nullptr on failure with the relevant Python exception and error set. | ||
*/ | ||
[[nodiscard]] auto to_dict() -> PyDictObject*; | ||
[[nodiscard]] auto to_dict() -> PyObject*; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just curious, any reason we don't return There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I used There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Tuple APIs would also return There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Gotcha. Right, I read from the https://docs.python.org/3/c-api/arg.html#c.Py_BuildValue docs that the API is not guaranteed to return a tuple, but since we have the format string fixed, it should not return anything else i assume. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Swith to PyTuple_Pack since it doesn't need argument parsing. |
||
|
||
private: | ||
static inline PyObjectStaticPtr<PyTypeObject> m_py_type{nullptr}; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not too sure how we are going to implement the compatibility layer for CLP Text IR Streams. In the future, will log events also be accessed through this interface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes,
timestamp
will be stored inside the auto-generated dictionary andmsg
will be stored inside the user-generated dictionary.