Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow user-specified Model base classes #72

Closed
wants to merge 1 commit into from
Closed

Allow user-specified Model base classes #72

wants to merge 1 commit into from

Conversation

jfinkels
Copy link
Contributor

This is in response to issue #62. It allows a user to specify a base class for models (which should be a subclass of flaskext.sqlalchemy.Model) in the constructor of flaskext.sqlalchemy.SQLALchemy. Note: this does not work with the SQLAlchemy.init_app(app) idiom unless the model class is specified in the constructor of SQLAlchemy.

@robcowie
Copy link

robcowie commented Jun 1, 2012

+1

7 similar comments
@luaz
Copy link

luaz commented Nov 23, 2012

+1

@hsk81
Copy link

hsk81 commented Feb 14, 2013

+1

@klinkin
Copy link

klinkin commented Feb 15, 2013

+1

@wtf
Copy link

wtf commented Apr 6, 2013

+1

@artnez
Copy link

artnez commented Jun 2, 2013

+1

@glyphobet
Copy link

+1

@johaness
Copy link

+1

@jamesonjlee
Copy link

-1
you should do this with mixins and explicitly declare the inheritance for the new models instead.

# a contrive example 
def Base(object):
    def say_hello():
        print "hello"
def User(db.Model, Base):
    pass
me = User()
me.say_hello()

if you needed the db.Model inside the Base, that's a different thing.
I use this to create delete, get_or_create, etc methods with the models.

@lepture
Copy link

lepture commented Jul 18, 2013

agree with @jamesonjlee . 👎

@davidism
Copy link
Member

Extending this to allow other custom bases such as DeclarativeMeta, BaseQuery, etc. would be really useful. Right now I end up subclassing and overriding the extension to use custom classes.

@ThiefMaster
Copy link
Contributor

👍 - this would still be increadibly useful and avoid nasty monkeypatching!

Using mixins instead is not a very good idea. You need to put them in every single model explictly even if you just want to add convenience methods which you do want in all your models.

@davidism
Copy link
Member

davidism commented Dec 6, 2015

#328

@davidism davidism closed this Dec 6, 2015
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.