Make sqlacode eaier to reuse / subclass about sqlacodegen HOT 11 CLOSED

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

Ok, I've done quite a bit of that refactoring now. Tell me how you feel about it.

EDIT: I realize that there is no meaningful way yet to control the way it generates column types yet, but I plan to add that before long.

from sqlacodegen.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

I've decided to refactor the codebase for easier reuse when the opportunity arrives. I'm hoping it will happen within this year. My $work backlog is too long for me to do it now.

from sqlacodegen.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

I'm open to the idea of making sqlacodegen more extensible. I'm not very open to making backend specific hacks, however, so the solution will be refactoring the code to better support extending the functionality. Your explanation gave me an easy use case to aim for when I do the refactoring. I can't promise when this will happen (I have $projects underway and I need to make a maintenance release of APScheduler), but I will get around to it eventually.

from sqlacodegen.

Original comment by y g (Bitbucket: ubershmekel, GitHub: ubershmekel):

I've made some local changes for making mysql's TINYINT(1) result in a Boolean as it should. Should I make a pull request?

Personally I'm using this on an ever-evolving database. I regenerate the ORM every once in a while to get all the new updates. I do not ever want to hand modify the resulting ORM. It's 766 lines long and we add a table or a column once a month which would be hairy to merge.

So if I had a way to extend sqlacodegen it would have been nice, but right now I have to fork and modify. Which brings me to the aforementioned potential pull-request.

from sqlacodegen.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

I would like to understand your use case before I make a decision one way or the other.

from sqlacodegen.

Original comment by xicesky (Bitbucket: xicesky, GitHub: xicesky):

I see, if the code in this repository is not meant to be reuseable, i'll stick with my own fork which works for me.

from sqlacodegen.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

Sqlacodegen was never meant to produce perfect output, but "good enough" to minimize the necessary modifications. It was meant as a bootstrapping tool to give the developer a starting point for the model code if they have a pre-existing schema.

You still have not explained what this special need of yours is that requires modification of the sqlacodegen code. Do you really need to generate code several times within the scope of the same project? I understand if you want to only produce Tables instead of declarative classes -- that could be done with far fewer modifications than what you're proposing.

from sqlacodegen.

Original comment by xicesky (Bitbucket: xicesky, GitHub: xicesky):

Additionally, writing reusable code adds a lot of value to your project imho. :)

from sqlacodegen.

Original comment by xicesky (Bitbucket: xicesky, GitHub: xicesky):

I have a pre-existing schema in my database with a lot of tables. I use sqlacodegen to generate a python model for this schema. But in order to use other tools (e.g. alembic migrations) i have to fulfill some conditions, like generating foreign keys with "use_alter = True".
Additionally i'd like to use SQLAlchemy Core and avoid declarative style for now.

I imagine there is a number of possible "special use cases" like this. Sqlacodegen does not have to support this out of the box, but if a developer is willing to invest time in some custom code, it should still be possible.

At the moment, if you are using Sqlalchemy from pypi (e.g. installing it in a virtualenv like i do), you shouldn't modify it's source directly, of course. But changing it's behaviour is really hard to do using the current design.

You might want consider just a few changes to codegen.py:

• Split up the huge constructor in a few easy-to-handle methods that can be overriden by subclasses.
• Allow swapping out ModelClass/ModelTable for subclasses of those.

Those two changes alone would already help a lot.

from sqlacodegen.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

What is the use case for this?

from sqlacodegen.

Original comment by xicesky (Bitbucket: xicesky, GitHub: xicesky):

Making this work would need quite a bit of refactoring i suppose. I am not an experienced Python developer, so i fear i'll break more code than fix issues ;)

Nevertheless i forked sqlacodegen and hacked away on the source, testing a few ideas of mine:

• I tried to introduce a "Context" like alembic migrations uses. In alembic, this object holds settings as well as delegates that can be overriden (by configuration) to e.g. filter tables or columns, change the way types are represented, ...
• I split the codegen.py file into codegen.py and util.py (the latter containing all the previously private utility functions that are used by default).

I did not make this a pull request since my code is bad, but you can still find it here for reference: https://bitbucket.org/xicesky/sqlacodegen-hg

from sqlacodegen.