New maintainer wanted

[agronholm]

I find myself stretched too thin to effectively maintain this project. It would be nice if someone capable took the reins from me.

[flipbit03]

I want in.

I have a specific need (to have the created model descend from a baseclass like the example below

I want an option to be able to declare the base in a separate file the way I need, like :

@as_declarative()
class BaseProdigioPG:
    def __repr__(self):
        try:
            pkid = getattr(self, 'id')
            return f"<{self.__class__.__name__} PK_ID={pkid}>"
        except:
            return f"<{self.__class__.__name__} at {hex(id(self))}>"

Instead of :

# BaseProdigioPG = declarative_base()

This way one can easily customize the base class and add repr and whatever they need

....and I saw your (help wanted) issue.

How can we do this? I"ll try to provide the feature I want and get acquainted with the code. Let's see if we can make this work. This is a super useful tool and I thank you for your time/effort in doing this 👊

[agronholm]

The point of sqlacodegen was to save developers time they would otherwise have to spend writing the model classes themselves – a process that is both tedious and error prone.

I don't see anything that would prevent you from having a separate base class like this. All you have to do is edit the generated result.

At any rated, are you interested in maintainership or just getting this specific feature in?

[flipbit03]

I have interest in both mantaining the code (managing the pull requests and fixes) and also to have my own set of features in.

I have a use case where I have to query a PostgreSQL database which is being upstreamed somewhere else by other api, so I'm always lagging behind and have to update my base model according to the changes. I have also customized my base model and changed its name to something else (which is always desirable instead of "Base"). I'd like to have those kind of features baked in instead of having to edit the code every time i regenerate it. Simple quality of life features but which can go a long way.

I also found a bug where using a field name (namely: "text") triggers the generation of an invalid model since the next 'text' field inside a generated class which has a "text" column will actually use the text "Column" object instead of the 'text' function of SQLAlchemy, so I was about to dive/understand how the importcollector works and maybe I could extend it to detect when it needs to alias the SQLAlchemy objects because of name conflicts in the tables.

Because of those issues I found and the needs I have, I came here to check the pull requests/issues and maybe file a few of my own, and found your request for help. So how do we go about this? Can I just submit a first pull request so you can analyze the way I refactor/work with things so you can assess stuff first? that's probably what i'm gonna do.

Anyways, thanks in advance for this wonderful piece of software which has saved me countless hours.

[flipbit03]

All you have to do is edit the generated result.

For example, having a flag that means "insert THIS import file at the beginning of the file and don't create a base, instead, expect name to be the base (and create the generated classes using this object which will be defined elsewhere)" would mean one less manual edit. specially for us that have to 'sync' files from databases that are migrated/managed by other tools.

hope I can be of service!

[agronholm]

Other people have been trying to use sqlacodegen for similar workflows, even though it wasn't designed for that. But, if you're willing to take up maintainership, you can steer the project in that direction. We can start the way you suggested: make a PR or two and we'll go from there.

[laurentS]

@agronholm I have a similar issue with a separate project that I started, which got more use than I expected (less than sqlacodegen, but that's not very relevant).
I got inspired by another project (I can't find it anymore, I wish I'd made a note of it) which took the route of adding every github member who contributed some code (PR, whatever you see fit) as a member of the project. Essentially this meant sharing the workload of reviewing PR, triaging bugs, etc...
I started doing this with the 6-7 contributors to my project a few weeks ago, so it's only very fresh, but overall, I'm seeing positive results: people review each other's PRs, start asking if they can cut a new release, etc...

Anyway, you might want to explore such an option as a possible path towards handing over maintainership of the project that is a bit less scary for other to jump into.

[agronholm]

The trio project at least did take that route. My only concern here is that this project could easily become unmaintainable when everyone adds their favorite customization hooks. Now with 3.0.0b2 out there, the need for a new maintainer is not that pressing. That said, I'm willing to experiment this if somebody wants to join the project as a contributor.

[anton-petrov]

Hi, @agronholm! Does the project still need new maintainers?
I recently tried it out and liked it. However, there are small bugs and roughness, but in general - sqlacodegen is a very indispensable thing. It's really awesome!

[agronholm]

Yes, I'd be interested in relinquishing maintainership after the next major release. Do you have any particular agenda for this project?

[leonarduschen]

Hi, I would love to explore taking up maintainership for this project!

Although, I was hoping that could I work under the guidance of someone more experienced (both on this particular codebase and open source maintenance in general, mostly the later) for some time before fully committing.

@agronholm perhaps you could supervise my work for the next few weeks and see how it goes? I could work through the existing bugs in the issue tracker (well I've just opened a PR for one of them) and perhaps add some new features in.

---

One feature I think would be great to have is to allow customization of constraint naming conventions. We already have utils.uses_default_name, but it's currently not super useful because sqlalchemy.MetaData.naming_convention is always {'ix': 'ix_%(column_0_label)s'} by default. (Reference: https://docs.sqlalchemy.org/en/14/core/constraints.html#the-default-naming-convention)

We can pass the naming conventions as command line args like

sqlacodegen --conventions '"ix": "ix_%(column_0_label)s", "uq": "uq_%(table_name)s_%(column_0_name)s", "pk": "pk_%(table_name)s"'

or maybe have it read from a JSON file for easier formatting.

The implementation would be pretty straightforward. We just need to modify the MetaData in cli.main.

We will also need to make utils.uses_default_name check MetaData.naming_convention properly; right now it just checks for abbreviations: "fk", "pk", "ix", "ck", "uq" but the actual Constraint classes (e.g., PrimaryKeyConstraint) are valid as well. (Reference: https://docs.sqlalchemy.org/en/14/core/constraints.html#configuring-a-naming-convention-for-a-metadata-collection)

EDIT: formatting, typo

[agronholm]

@leonarduschen sounds good on the general level. I do question naming conventions being passed on the command line. That rabbit hole goes pretty deep when everybody wants to customize every aspect of the code generation step. A YAML or TOML based configuration file would be better. I'm looking forward to seeing what you come up with.

My intent with the next release is to create a system where you could have your own generator that just gets passed elements to be formatted (tables, classes, whatnot). If would then generate the code, optionally falling back to the default behavior.

[agronholm]

I've fixed all of the reported bugs so far so I've gone ahead and release v3.0.0rc1. I'm still not happy with the way import collection and rendering mesh together (or not) internally, so anybody taking on maintainership should find a better way to deal with that. @leonarduschen how about I pass the baton to you after 3.0.0 final?

[leonarduschen]

Hi @agronholm , apologies for the prolonged silence, I've been wanting to get back to you on this

---

My intent with the next release is to create a system where you could have your own generator that just gets passed elements to be formatted (tables, classes, whatnot). If would then generate the code, optionally falling back to the default behavior.

Are you referring to the current "option" to subclass the existing generator classes as mentioned in https://github.com/agronholm/sqlacodegen#customizing-code-generation-logic ? Or is it something new that you wish to have in the next release (i.e., not 3.0.0) ?

I'm still not happy with the way import collection and rendering mesh together (or not) internally, so anybody taking on maintainership should find a better way to deal with that.

Well one area of improvement, I think, is how we do duplicated conditional checks for constraints on collect_imports_for_constraint and render_column. I'm guessing you're seeing something else on top of this - I'd be happy to hear your thoughts on this if you could elaborate on the details. Perhaps we should create a separate issue for the discussion.

---

@leonarduschen how about I pass the baton to you after 3.0.0 final?

I'm still not yet as comfortable with the codebase as I would ideally like myself to be, but if you'd still be participating in discussions from time to time I think we're good! I could definitely use your opinion on design decisions, possible features, etc - especailly early on.

[agronholm]

I think we need to support a configuration file to support all these options. They are getting more complex than can be reasonably supported as command line switches.

[agronholm]

Why the thumbs down?

[flipbit03]

I think a configuration file should only be considered after we finally find that something is difficult or impossible to do via the current configuration interface, which is the CLI.

I believe adding another interface and now having to coalesce from 2 sources of configuration inputs is extra work in documentation, testing and general wrangling, and that should only be pursued if it's an absolute necessity.

[agronholm]

The configuration file can certainly be deferred to a minor release after 3.0.

[sheinbergon]

@agronholm are you still looking for a maintainer?

[agronholm]

@agronholm are you still looking for a maintainer?

Yes, as I don't really haven't had the bandwidth to develop this.

[sheinbergon]

@agronholm much like you, I'm quite a busy bee. However, I find you project quite useful, and have been using it successfully in a few production environments. I would mostly be happy to see an official version release for the 3.0.x branch. Can we map out a clear path to make it happen (which PR's are relevant, which issues require attentions). I can spare the time and work towards making it happen.

Unlike other people in this thread, I don't want to add a specific missing feature, just more interested in clearing the table and help make this project move forward.

Does that sound relevant? working with a contributor to move things forward?

[agronholm]

@agronholm much like you, I'm quite a busy bee. However, I find you project quite useful, and have been using it successfully in a few production environments. I would mostly be happy to see an official version release for the 3.0.x branch. Can we map out a clear path to make it happen (which PR's are relevant, which issues require attentions). I can spare the time and work towards making it happen.

Unlike other people in this thread, I don't want to add a specific missing feature, just more interested in clearing the table and help make this project move forward.

Does that sound relevant? working with a contributor to move things forward?

Sure! I think where I went wrong with this release cycle was trying to make everyone happy who wanted to customize the generation. This massively increased the complexity and workload. Perhaps I should've just turned them down, as such customization was not in the original scope. How do you feel about this?

[sheinbergon]

Sounds good. Is the current milestone, consisting of 3 issues (1 closed, 2 open) still relevant?
Do you want to map other issues or the entire milestone differently?

[agronholm]

The "improve design" ticket is a bit broad, and I'm not sure what needs to be done to that end. What's important is to close any "important" bugs, like broken SQLModel support. You could also go through the list and suggest issues to be fixed for the 3.0.0 final.

[sheinbergon]

@agronholm so maybe remove that design issue from the milestone.
I have no idea what you consider as important, so if you could just do the part of adding milestone lables for what you deem as such, I (and hopefully other people as well) can start moving towards resolving them.

As for SQLModel support, I guess it could be a good starting point. If I open a PR for that, would you have the capacity to merge (and review) it?

[agronholm]

I'll make the time for that.

[agronholm]

I've updated the milestone to include issues and PRs I would like to be addressed for 3.0 final.

[agronholm]

Just to clarify: having PRs in the milestone doesn't mean they should be merged, but a decision should be made whether to merge, reject or defer them.

[faizanazim11]

I am glad to see some progress happening in this project as I am also using this package in few production scenarios. I would also like to contribute to this project but can't take maintainer role.

[sheinbergon]

@agronholm yalla, which issue should we tackle next?

[agronholm]

I opened a discussion where we can continue without pinging anyone who just wants to know about the maintainership issue.