> Honestly, I don't think we'd release this as a third party package. We have > had to code around a lot of core db specific code to get Snow SQL to work
This is good feedback that is valuable for us to hear. Even if you don’t release it as a fully maintained package just understanding the pain points you encountered while developing this is great feedback that can help us improve. Would you be willing to share specific code snippets here, or just general areas that you found challenging while developing this backend? > That's what has made the process harder than it should be to support a > non-core db. It creates second class system support in favor of the core dbs > that are code and tested against. Remove all of the db backends and make > them all third party and you'd see a lot more db support. I can see a world where even core Django database backends are much more plugin oriented and could definitely bring some advantages. But that’s a non-trivial task with a lot of constraints especially for a fairly community driven project like Django. Tom > On 22 Jan 2021, at 22:34, Scott Fought <fougb...@apps.disney.com> wrote: > > Snowflake (at this point) isn't as fast as PostgreSQL for smaller > transactions. PostgreSQL couldn't handle the performance we needed to drive > our apps and we really didn't want to support a hybrid db app. We give up a > little speed for the convenience of having everything in one system. At a > recent Snowflake event, they stated that 30% of their users were using > Snowflake for application backends. They are also working to improve their > execution time on smaller transactions. > > Honestly, I don't think we'd release this as a third party package. We have > had to code around a lot of core db specific code to get Snow SQL to work. > If there was a hard API for DB backends my response would be different. It > would only make sense for us if this backend were part of standard Django > testing and support consideration. > > "Merging the backend straight to core would impose the requirement that all > changes to Django core consider Snowflake" > That's what has made the process harder than it should be to support a > non-core db. It creates second class system support in favor of the core dbs > that are code and tested against. Remove all of the db backends and make > them all third party and you'd see a lot more db support. > > Scott > >> On Friday, January 22, 2021 at 5:22:24 PM UTC-5 Adam Johnson wrote: >> Yes we would favour a third party backend. Merging the backend straight to >> core would impose the requirement that all changes to Django core consider >> Snowflake, which is a fairly steep cost when there's only one organization >> using it (at current). If you release as a third party package and show some >> adoption, it could then be argued that it's worth merging. >> >> Additionally Scott - would love to see Disney appear on this page, perhaps >> the "Platinum" section would feel comfortable: >> https://www.djangoproject.com/fundraising/ ;) >> >>> On Fri, 22 Jan 2021 at 21:57, Tom Forbes <t...@tomforb.es> wrote: >>> I think this should definitely be released as a third party package, and if >>> there is enough community interest it might be considered for inclusion. We >>> could definitely update the docs to link to the package though. >>> >>> On a side note, is Snowflake fast enough for general purpose web apps? When >>> we evaluated it the performance characteristics where similar to Redshift, >>> optimised for large analytical aggregation rather than fast, smaller result >>> sets typically seen with Django apps. >>> >>> Tom >>> >>>>> On 22 Jan 2021, at 21:49, Scott Fought <foug...@apps.disney.com> wrote: >>>>> >>>> >>>> We have written a Snowflake DB backend that we use internally in several >>>> projects and are considering releasing it for public use. My preference >>>> would be to incorporate it as a core backend so the nuances of Snowflake >>>> SQL are considered when changes are made to the core system. Is this >>>> something we should pursue? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Scott >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Django developers (Contributions to Django itself)" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to django-develop...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/3e5034a8-6c75-4f28-9830-2c87b671ae86n%40googlegroups.com. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to django-develop...@googlegroups.com. >> >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/08448193-19F7-4AA8-A112-ED6802DC7FBF%40tomforb.es. >> >> >> -- >> Adam > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/cb99116e-65a8-458c-87a1-74458194d741n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9F0317A9-DCF8-40C2-903C-C4EE8194BD1D%40tomforb.es.
