-
Notifications
You must be signed in to change notification settings - Fork 3
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: request contextualisation - core functionality #65
base: main
Are you sure you want to change the base?
Conversation
…turn List[MethodParamWithTyping] required to construct ExposedFunction dataclass
Code Coverage Summary
Diff against main
Results for commit: 1294a9c Minimum allowed coverage is ♻️ This comment has been updated with latest results |
…bugfix; fixed linting issues
…aseCallerContext subclasses from the Union[] args; linting fix
…ss + type hint improvements: fixes, new generics and aliases
…nt when it detectes the additional context is required
…jc/issue-54-request-context
0ded684
to
9ba89e5
Compare
…pylint; run pre-commit auto refactor
Trivy scanning results. |
7a49b4d
to
3c87020
Compare
…ity and properly handle types: Union[Type1, Type2, ...], __main__.SomeCustomClass
3c87020
to
c0b0522
Compare
44a2fdc
to
2d0ef4b
Compare
src/dbally/context/context.py
Outdated
CustomContext: TypeAlias = "BaseCallerContext" | ||
|
||
|
||
class BaseCallerContext(BaseModel): |
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.
pydantic is not a required dependency at the moment, and we should avoid it if possible (v1 vs v2 issues). Maybe a bare dataclass is enough here?
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.
We can still support pydantic models as context, but we shouldn't enforce it
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.
Fixed, thanks :)
src/dbally/iql_generator/prompt.py
Outdated
@@ -74,6 +74,10 @@ def __init__( | |||
"You MUST use only these methods:\n" | |||
"\n{filters}\n" | |||
"It is VERY IMPORTANT not to use methods other than those listed above." | |||
"Finally, if a called function argument value is not directly specified in the query but instead requires knowledge of some additional context, than substitute that argument value by: BaseCallerContext()." |
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.
maybe just Context()
?
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.
Right. I will adjust it.
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.
Done. Thanks :)
…), supporting both dataclasses and pydantic
…hat a context is required
f78c101
to
3423033
Compare
src/dbally/context/_utils.py
Outdated
filter_method_: type_ext.Callable, hidden_args: Sequence[str] | ||
) -> Tuple[Sequence[MethodParamWithTyping], ContextClass]: | ||
""" | ||
Processes the MethodsBaseView filter method signauture to extract the args and type hints in the desired format. |
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.
Typos: "signauture", "claases", "are getting excluded the returned"
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.
Thanks.
src/dbally/context/context.py
Outdated
a class implementing this interface, selected based on the filter method signature (type hints). | ||
""" | ||
|
||
_alias: str = "Context" |
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.
nit: instead of providing a default value, I would require inheriting classes to define their own (throw exception otherwise or even better use an abstract method definition), to ensure that they don't use the default value by accident. Especially since it might be easy for people to assume that the name of the class itself is used as an alias automatically.
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.
Please update the docs on how contexts are defined and how they work.
) | ||
except IQLError as exc: | ||
# TODO handle the possibility of variable `response` being not initialized |
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.
How can it be not initialized at this point?
|
||
Returns: | ||
Generated IQL query. | ||
""" | ||
prompt_format = IQLGenerationPromptFormat( | ||
question=question, | ||
filters=filters, | ||
examples=examples, | ||
examples=examples or [], |
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.
This is handled in the PromptFormat
initializator.
src/dbally/context/exceptions.py
Outdated
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.
All dbally exceptions should inherit from dbally.exceptions.DbAllyError
. To be consistent with the rest of the code base:
BaseContextException
should inherit fromDbAllyError
- rename
BaseContextException
->ContextError
- use inheritance for
ContextNotAvailableError
andContextualisationNotAllowed
…mples to the prompt
src/dbally/iql_generator/prompt.py
Outdated
@@ -74,6 +74,12 @@ def __init__( | |||
"You MUST use only these methods:\n" | |||
"\n{filters}\n" | |||
"It is VERY IMPORTANT not to use methods other than those listed above." | |||
"To specify a reference to the query execution context, as an API function argument, please call: AskerContext()." |
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.
Looks pretty good, although for me including an "if" statement would also be okay, as long as it directly references user's question (and not some other hidden parts of the system). For example:
"If the question does not include an explicit value for a function argument and instead references the execution context, use the ASKER_CONTEXT constant as a placeholder."
(may be modified for the "AskerContext()" function-like syntax, although I like the simplicity of asking the LLM to use a constant - asking it to "call" something seems a bit more complicated, potentially causing more varied outputs).
Anyway, we should ultimately test multiple versions anyway. What's important for me is that we test for false-positives (i.e., we have solid test cases for various situations when a filter supports context in general but it should not be used for the particular query) - false-positives is the thing that worries me the most at the moment.
…, b] -> a | b; removed typing & typing_extensions module name prefixes
b5827c9
to
1294a9c
Compare
Closes #54