You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I really appreciate spyql flexibility and the fact that it supports many formats, but what if I want to add my own format support?:slightly_smiling_face:
My use case: I have custom data format, and I parse it to dataclasses. For example:
@dataclass
class MyData:
field_one: str
field_two: str
Now, I want to be able to run queries on a list of these dataclasses instances:
data = [DataClass("one", "1"), DataClass("two", "2"), DataClass("three", "3")]
# ...
query = Query("""SELECT row.field_one FROM data""")
query(data)
Of course, this does not work, since the attributes are queried directly with dict.__getitem__.
I understand, I can use dataclasses.asdict, but this approach is not flexible enough, because I also want to use arbitrary properties and functions in my queries. This would mean that everything should be converted to dictionaries ahead of time, what might be costly.
Could you please add some abstraction to allow custom types in queries? Something like:
The idea is great! I cannot implement it right now (no bandwidth at the moment), but you are welcomed to submit a PR :-) Let me know before start coding if you would to like to contribute. Thanks!
I really appreciate spyql flexibility and the fact that it supports many formats, but what if I want to add my own format support?:slightly_smiling_face:
My use case: I have custom data format, and I parse it to dataclasses. For example:
Now, I want to be able to run queries on a list of these dataclasses instances:
Of course, this does not work, since the attributes are queried directly with
dict.__getitem__
.I understand, I can use
dataclasses.asdict
, but this approach is not flexible enough, because I also want to use arbitrary properties and functions in my queries. This would mean that everything should be converted to dictionaries ahead of time, what might be costly.Could you please add some abstraction to allow custom types in queries? Something like:
The text was updated successfully, but these errors were encountered: