From Olly Cope to ~olly/yoyo
Thanks, applied! On 29/04/2024, b@b3n.eu wrote: ># HG changeset patch ># User b3n4kh <b@akhras.at> ># Date 1714424587 -7200 ># Mon Apr 29 23:03:07 2024 +0200 ># Node ID b21e6753a7fe3d44f46255933a9700556f0a193f ># Parent 5875ba420a0e3e08c3f9b7022c821af0ee5659f7 >Fixes Issues #94 #96 > >pkg_resources is deprecated see: https://setuptools.pypa.io/en/latest/pkg_resources.html >This throws a warning on every currently supported python version. >Additionally this breaks yoyo migrate if not manually installed setuptools, which currently isn't a dependcy.
From Olly Cope to ~olly/yoyo
On 22/12/2022, Herman Eyd wrote: > >I’m testing your tool and i can’t find any descriptions about script hash mechanism behavior. For example Java FlyWay tool will be throw an exception if already applied migrations were changed. But with your tool i can change applied migrations and nothing happen. Is it ok or it is a bug? > It's not something I've thought about before. Not a bug, but some people might consider it a missing feature :) Does FlyWay have a good way to handle situations where it is necessary / desirable to change a migration that is already applied? Olly.
From Olly Cope to ~olly/yoyo
Hi Anslem, >Your patch works for me. It is indeed much simpler than mine. > Since writing that patch I rediscovered this: https://todo.sr.ht/~olly/yoyo/4 Because my patch breaks that earlier fix, I'd now prefer not to apply it. >Another observation: the function topological_sort() might be to >aggressive. Given I have three migrations in this order by ID: >"m1.sql", "m2.sql", "m3.sql" and "m3" depends on "m1" >Currently topological_sort() yields "m1", "m3", "m2". But the initial
From Olly Cope to ~olly/yoyo
On 07/04/2021, Charles Julian Knight wrote: ># HG changeset patch ># User Charles Julian Knight <julian@fixdapp.com> ># Date 1617846311 14400 ># Wed Apr 07 21:45:11 2021 -0400 ># Node ID 1877b318c67a8058f296211dfd34b1de28e693e8 ># Parent b4d81daa2515ad7ab9e0def1dd2894f235e7b667 >Support for snowflake connect parameters > >For the snowflake database, I ended up needing to configure the role option. > >This change passes all query options to 'snowflake.connector', allowing you >to set any of the parameters snowflake supports. The full list is available
From Olly Cope to ~olly/yoyo
Thanks! This looks really good. I'm excited to have a look at that algorithm, it's new to me and looks pretty interesting. I'll review your patch for inclusion as soon as I can (but I have a lot on right now with other work so it might not be until next week). Olly. On 13/04/2021, Kruis, Anselm wrote: >Hi, > >below is the patch. > >-----Ursprüngliche Nachricht----- >Von: Kruis, Anselm
From Olly Cope to ~olly/yoyo
On 26/03/2021, Kruis, Anselm wrote:
>
>Now, if migration "test/05.sql" declares a dependency on "prod/04.sql" I get the following order:
>
>"test/01.sql",
>"test/02.sql",
>"prod/04.sql",
>"test/05.sql",
>"prod/03.sql",
>"prod/06.sql"
>
>This changes the application order for productive migrations from 03, 04, 06 to 04, 03, 06. That is, I get different ordering of the productive migrations for PROD-DB and DEV-DB. That is not so good.
>
>Therefore I would like to add an option to sort all migrations by their ID. Then I get this order:
[message trimmed]
From Oliver Cope to ~olly/yoyo
On 18/01/2021, Daniele Pizzoni wrote: > # HG changeset patch > # User Daniele Pizzoni <d.pizzoni@feedstock.com> > # Date 1610961129 -3600 > # Mon Jan 18 10:12:09 2021 +0100 > # Branch redshift > # Node ID 8ecf65ff2fafadc4195d14e8939f04ae2a5ab833 > # Parent d8495101e8c79ed93e153c948deeaedfc3fda580 > Add AWS Redshift support > Thanks, that looks good. Applied.
From Oliver Cope to ~olly/yoyo
On 24/12/2020, Josha Inglis wrote: > # HG changeset patch > # Date 1608758195 -39600 > # Thu Dec 24 08:16:35 2020 +1100 > # Node ID 53138827a7d7cbeb811e404a0a169edee486b9e6 > # Parent d8495101e8c79ed93e153c948deeaedfc3fda580 > Add -o flag to force post-migrations to be run > This looks good, thanks! I'm wondering about making this a long option only (--force-post-migrations). "-o" doesn't feel like it has a natural connection to the long option name and I wonder if we really need a short option for this feature.
From Oliver Cope to ~olly/yoyo
On 26/12/2020, Alexander Myltsev wrote: > > $ yoyo apply --config yoyo-dev.ini > ERROR:yoyo.migrations:Could not import migration from > '/demo-app/db-migrate/migrations/20201220_01_abcd-test.py': > ModuleNotFoundError("No module named > '/demo-app/db-migrate/migrations/20201220_01_abcd-test'") > Traceback (most recent call last): > File "~/Library/Caches/pypoetry/virtualenvs/db-migrate-48SoZt4C-py3.8/lib/python3.8/site-packages/yoyo/migrations.py", > line 223, in load > spec.loader.exec_module(self.module) > File "<frozen importlib._bootstrap_external>", line 783, in exec_module > File "<frozen importlib._bootstrap>", line 219, in > _call_with_frames_removed
From Oliver Cope to ~olly/yoyo
On 24/11/2020, Alexander Myltsev wrote: > > I'd like to create a dev migration that seeds a database with sensitive > information (emails, passwords, etc.). I'd like to put that info in a > PyHOCON config section. And then transform it to a series of steps. I'd like > to share app.conf between transaction files. When I try to import config.py > from local directory, yoyo blames that > ModuleNotFoundError(migrations/20201110_01_9byAr-some-transaction.py). > What's the proper way to do it? > This sounds like it should be doable, but I don't understand how you have it set up at the moment. Are you able to post some of your code? Olly.