This of course does not mean we will stop development on the Atlan Python SDK.
As new features and functionality are released in Atlan, the SDK will continue to evolve.
If any s appear, we'll fix those, too.
Please continue to provide feedback on the Python SDK as you use it, so we can continue to evolve it to best meet your needs!
Although we reserve the right to make exceptions to this rule should any back-end changes prevent us from logically deprecating something, due to it entirely changing or disappearing. (Such a circumstance should be exceptionally rare, though.) ↩↩↩
If you are super search-savvy, you may already be familiar with Elastic and its power and flexibility. However, we understand not everyone has these skills — and for many of us having a basic and easy-to-use search mechanism can be desirable.
That's where fluent search comes in!
It's meant to be easy to learn, quick to do the basics, but also capable enough to address fairly powerful search use cases.
Fluent search is just a set of classes and methods over the same back-end APIs. So your queries will run as fast as ever, but defining them should now require less effort.
It'll probably help to look at a side-by-side comparison. Let's use one of our existing examples to illustrate. In this scenario, imagine you are searching for all assets that are marked as verified but are missing a description (suggesting they are in fact incomplete):
You used to need to static-import a QueryFactory to get access to various helper methods like where.
Adding a condition to a query was then fairly complex task of combining these helper methods with enumerations, where you needed to know how a field was indexed (keyword vs text vs numeric) to find it and add it.
You still had to know the exact names, spelling and capitalization of attributes to ensure they were included in each result.
Now you no longer need the QueryFactory — you can directly chain where and whereNot clauses into the query. Even better, the attributes now self-restrict how you can search them based on their type — you no longer need to know how the fields are indexed.
You no longer need to rely on typo-prone strings to list the attributes to include on results, either!
Now you can compose queries against any searchable attribute in Atlan. The operations you can carry out against each attribute are determined for you based on the kind of attribute you're searching.
Different methods make it clear whether your condition will be used to include (where()) or exclude (where_not()) results, without needing to rely on arithmetic operations like + and ~.
You can chain other criteria like which attributes to include in each result directly onto the search, no need to build DSLs and then requests. And no need to rely on typo-prone strings anymore, either!
You can still translate the fluent query into a request.
And you can then run your search and iterate through the results just like before.