29 Replies
you mean you want to see how it looks for the AI?
the schema is generated from your linked action
yes I need to see the argument it exposes because the AI is making invalid calls that result in the db query failing
IIRC there is a debug or verbose flag in langchain to see exactly what it's doing
And also a function like
AshAi.parameter_schema
or something that will give you the schema@Zach The thing is I have an {:array, :string} field that I want the llm to provide a value and check whether it exists in the record.field or not, @barnabasj told me about :in filter but it does the reverse of what I want. and when I looked at the tool definition the only filter exposed by ash by default for {:array, :string} fields is is_nil.
I think the naive approach would be to add an argument to the action and then do it myself
That is the best way to do it 👍
the pre-built filters can't do everything
the issue is that I have 12 fields like that :[
There will always be things the builtin filters can't do
we can add a
contains
or member
or has
operator and then lift that up to the automatic filter stuff using arrays
but its not going ot be something that can happen in the short term unfortunatelyI think for postgres it's pretty straight forward "@@" and "= ANY"
I will be will to PR it
Its more complicated to set up than you realize 😄
I don't know how it would mess with the other datalayers
First, a
has
function needs to be PRd to Ash core, similar to in
basically copy that implementation
and type it as [:same, {:any, :same}]
and then a PR to ash_sql
to implement the expression in expr.ex
And then maybe some logic in ash_ai
to pick that up, not sure 😄I have some days off I will try to work on it
maybe I don't know what I am getting myself into
also while we're at it, an intersection function would be valuable too the "&&" operator
shouldn't the type be [{:array, :same}, :same] because the lhs will have the array
Yeah if its
has
then yeah, as in has(list, thing)
👍thank you
I noticed something in the Opertor.In code, when we compare 2 predicates, if we add 2 subset checks we can tell if it will be :right_includes_left or vice versa
False alarm
just don't mind this
the issue is that if it's not in the small MapSet we will still need to check that it's in the big one.
There is no equivalency
Don't worry about those callbacks TBH
They aren't really used for anything currently
I think I understood the idea basically compare is used to reduce the predicates and for example left_includes_right means that if left is false right is false
here the code for has
@Zach
Can't review at the moment but happy to review in PR 👌
is it the only thing that I should modify in core?
You'd need to also include those in the list of functions in
Ash.Query.Filter
And write tests for themGitHub
feat: implemented 'has' and 'overlaps' operators by moutikabdessabo...
Initial implementation of has and overlaps operators to allow for intersection and inclusion checks against array fields
Contributor checklist
Leave anything that you believe does not apply uncheck...
for tests I will need to add them to
test/filter/filter_test.exs
right?
I will need to probably add an array attribute to the resource for Ets datalayer tests
but should I add tests here following the same patterns used with in?Probably yes 🙂
I'm on an airplane
Don't want to load up the core
**code
But if it's got tests for
in
then it's good for the otherssorry for bombarding you, and thanks for your patience
All good 😂
@Zach I added the tests
I will look this week
In github You mentioned that it should be implemented as functions
Yeah, there are operators and functions
See something like
string_concat
But it's probably fine as is TBH
Well...not sure will see what it looks likeOne question, in ash_sql what are the providers that the changes should support, Sqlite/Postgres...