Yes. Agree with Andrey. I think our experience from the last few years was
"very" bad. The number of mssql users is very small. And the time that
maintainers and community members lose on various problems with it is huge.
Quite often every time we added a new feature requiring some new db
function
I don’t think there is any possibility left to keep MS SQL Server as DB
backend for Airflow.
I add Elad's message from the original discussion:
https://lists.apache.org/thread/r06j306hldg03g2my1pd4nyjxg78b3h4
Because it cleary describe what is happen with MS SQL as DB backend for the
last 1.5 year
+1
Definitely a +1 from me, seems like a relatively small effort to get good
returns
--
Regards,
Aritra Basu
On Tue, Oct 24, 2023, 11:01 PM Vincent Beck wrote:
> +1 I like this one. I think it is totally worth it adding this decorator,
> mostly because I think the effort is not huge. I also thi
+1 I like this one. I think it is totally worth it adding this decorator,
mostly because I think the effort is not huge. I also think, as a contributor,
it is a good exercise to, when writing tests, figure out whether the tests I am
writing is using the DB.
On 2023/10/24 16:31:57 Jarek Potiuk w
Hi Andrey,
We discussed internally (at Astronomer) regarding your
suggestion on the PRs and we will incorporate the suggestion
in our PRs to remove the callable approach and include
examples in the docs to achieve the same using TaskFlow
and using hook methods in those. Thank you for
the sugges
Those look like great ideas.
On Tue, Oct 24, 2023 at 4:23 PM utkarsh sharma
wrote:
> Just forgot to mention in my previous mail, that I'm suggesting the above
> changes since the storage is not the primary concern right now but I'm
> happy to contribute either way. :)
>
> On Tue, Oct 24, 2023 at
Hello everyone,
*TL;DR; *I have a proposal on how we can probably significantly decrease
time needed to run our CI tests. All that at the expense of small - I
think- effort by the need to mark tests as "db-tests" by contributors
enforced by our CI (in most cases that won't even be needed)..
*A
Just forgot to mention in my previous mail, that I'm suggesting the above
changes since the storage is not the primary concern right now but I'm
happy to contribute either way. :)
On Tue, Oct 24, 2023 at 7:43 PM utkarsh sharma
wrote:
> Hey everyone,
>
> I have a couple of tasks in mind, that mig
Hey everyone,
I have a couple of tasks in mind, that might aid in reducing the efforts
while working with docs. Right now tasks listed below are difficult to
achieve.
1. Adding a warning based on a specific provider/version of a
provider/range of providers. Which was also the task that Ryan was w
So it looks like we have some helping hands and we need someone to lead it
:) (just saying).
On Tue, Oct 24, 2023 at 8:15 AM Amogh Desai
wrote:
> +1 (non binding) from me on the thought of moving the older docs (~18
> months seems ok) to an archive instead of the repository.
>
> Coming to the ot
> It is in s3fs which relies on aiobotocore which relies on a specific set
of versions botocore
I think there is a little more to it (but it looks like it's being solved
as we discuss it).
It's also partially with coordination of releases and having pinned
dependencies between the fsspec API and
+1 from me as well, this should enable a lot of new usecases
--
Regards,
Aritra Basu
On Tue, Oct 24, 2023, 11:47 AM Amogh Desai wrote:
> +1 from me as well. Looks like something that the dev community would be
> interested in using and hence contributing as well!
>
> Thanks & Regards,
> Amogh D
12 matches
Mail list logo
