I want to specify a column in my sqlalchemy model to only accept values that are in a predefined list (in the example below ['bar','baz'].
Below is a minimal example of what such a model would look like
class Foo(db.Model):
"""Example Model"""
# simple autoincrement primary key
id: int = db.Column(db.Integer, primary_key=True, autoincrement=True)
# this column should be constrained to ['bar', 'baz']
exclusive_str: str = db.Column(db.String, nullable=False)
I found the check constraint in the official documentation, but the examples listed are super simple and don't seem to cover a use case like the above. How do I go about solving this?
Related
I am trying to save a list of VLAN IDs per network port and also per network circuit. The list itself is something like this:
class ListOfVlanIds(Base):
__tablename__ = 'listofvlanids'
id = Column(Integer, primary_key=True)
listofvlanids_name = Column('listofvlanids_name', String, nullable = True)
And I then have a Port
class Port(Base):
__tablename__ = 'ports'
id = Column(Integer, primary_key=True)
listofvlanids_id = Column('listofvlanids_id', ForeignKey('ListOfVlanIds.id'), nullable = True)
and a Circuit:
class Circuit(Base):
__tablename__ = 'circuits'
id = Column(Integer, primary_key=True)
listofvlanids_id = Column('listofvlanids_id', ForeignKey('ListOfVlanIds.id'), nullable = True)
Running code like this results (for me) in a sqlalchemy.exc.NoReferencedTableError error on the ForeignKey.
Looking for the error I read I should add a relationship back from the list. I haven't found a way (or an example) where I can build this from both Port and Circuit. What am I missing?
Creating a list table for Ports and Circuits just moves the problem downstream, since a VLAN ID is it's own table... I'd love to be able to use ORM, instead of having to write (a lot of) SQL by hand.
ForeignKey expects a table and column name, not model and attribute name, so it should be ForeignKey('listofvlanids.id').
I am writing a script which can pull data from different API's and store into a MySQL database. This application will run from command line. So I am only using Django's ORM.
But when I am creating a model which doesn't have primary key but have a column named id. When I am trying to save data in this model I am getting a error django.db.utils.IntegrityError: (1048, "Column 'id' cannot be null")
I am really confused why this happens. Because from API I get values from id column and there is no chance to get null or empty value for this column.
Please suggest me what I am doing wrong here.
Here is my model:
class Graphite(models.Model):
class Meta:
db_table = 'graphite'
id = models.BigIntegerField()
full_name = models.CharField(max_length=250, null=True)
email = models.CharField(max_length=250, null=True)
status = models.CharField(max_length=150, null=True)
And this is the code when I am trying to save data in this model:
Graphite.objects.using('database_name').create(
id=row['id'],
full_name=row['full_name'],
email=row['email'],
status=row['status'])
When saving data into model I am using Graphite.objects.using('database_name'). because I have multiple database connected in this application.
Well I'm not sure did you use django migrations, but it won't let you create this kind of model in django, where your id property (in model) hasn't primary key as its parameter (mySQL). So why don't you just define:
class Graphite(models.Model):
class Meta:
db_table = 'graphite'
id = models.BigIntegerField(primary_key=True)
full_name = models.CharField(max_length=250, null=True)
email = models.CharField(max_length=250, null=True)
status = models.CharField(max_length=150, null=True)
so set primary_key on id? Then you wouldn't have to pass id when creating Graphite.
BUT
If you have to provide id which is something you need to have in every Graphite model and it's something different than primary key, then just define it different, let's say row_id. But you should still have at last one id property in your model with primary_key set to True when you want to have id as BigIntegerField.
EDIT (on the example)
In mySQL execute this command:
ALTER TABLE graphite ADD COLUMN row_id BIGINT;
Then your model should looks like this:
class Graphite(models.Model):
class Meta:
db_table = 'graphite'
row_id = models.BigIntegerField()
full_name = models.CharField(max_length=250, null=True)
email = models.CharField(max_length=250, null=True)
status = models.CharField(max_length=150, null=True)
And usage:
Graphite.objects.using('database_name').create(
row_id=row['id'],
full_name=row['full_name'],
email=row['email'],
status=row['status'])
and that's it.
The problem is that you do not have a primary key.
From the docs:
Each model requires exactly one field to have primary_key=True (either explicitly declared or automatically added).
So, you have to make your id field a primary key by adding primary_key=True. Then, it won't complain.
You are overriding id from default django table id.
so there is no id for primary key. Just make it primary=True. or use another id like graphaite_id
You are missing your primary key, make sure you have your primary=True and to store your id make another column for it
I'm using alembic to maintain my tables. At the same time, I update my models using the declarative way.
This is one the alembic's table:
op.create_table(
'groups',
Column('id', Integer, Sequence('group_id_seq'), primary_key=True),
Column('name', Unicode(50)),
Column('description', Unicode(250)),
)
And the model is like the following:
class Group(Base):
__tablename__ = 'groups'
id = Column(Integer, Sequence('group_id_seq'), primary_key=True)
name = Column(Unicode(50))
description = Column(Unicode(250))
def __init__(self, name, description):
self.description = description
self.name = name
You can see, I'm using the Sequence in both the alembic migration and in the declarative model.
But I have noticed that when using PostgreSQL (v9.1) no sequences are created by alembic, and so the models fail to create instances since they will use the nextval(<sequence name>) clause.
So, how can I create my alembic migrations so that the sequences are truly generated in postgresql?
Just add following to your model:
field_seq = Sequence('groups_field_seq')
field = Column(Integer, field_seq, server_default=field_seq.next_value())
And add following to your migration file (before creating table):
from sqlalchemy.schema import Sequence, CreateSequence
op.execute(CreateSequence(Sequence('groups_field_seq')))
Found a hint at https://bitbucket.org/zzzeek/alembic/issue/60/autogenerate-for-sequences-as-well-as#comment-4100402
Following the CreateSequence found in the previous link I still have to jump through several hoops to make my migrations works in SQLite and PostgreSQL. Currently I have:
def dialect_supports_sequences():
return op._proxy.migration_context.dialect.supports_sequences
def create_seq(name):
if dialect_supports_sequences():
op.execute(CreateSequence(Sequence(name)))
And then call the create_seq whenever I need it.
Is this the best practice?
Not sure if I got your question right but as nobody else chose to answer, here is how I get perfectly normal ids:
Alembic:
op.create_table('event',
sa.Column('id', sa.INTEGER(), autoincrement=True, nullable=False),
The class:
class Event(SQLADeclarativeBase):
__tablename__ = 'event'
id = Column(Integer, primary_key = True)
I ran into this same issue recently and here is how i solved it.
op.execute("create sequence SEQUENCE_NAME")
I ran the above command inside the upgrade function and for the downgrade run the below code inside the downgrade function respectively.
op.execute("drop sequence SEQUENCE_NAME")
I have some code here. I recently added this root_id parameter. The goal of that is to let me determine whether a File belongs to a particular Project without having to add a project_id FK into File (which would result in a model cycle.) Thus, I want to be able to compare Project.directory to File.root. If that is true, File belongs to Project.
However, the File.root attribute is not being autogenerated for File. My understanding is that defining a FK foo_id into table Foo implicit creates a foo attribute to which you can assign a Foo object. Then, upon session flush, foo_id is properly set to the id of the assigned object. In the snippet below that is clearly being done for Project.directory, but why not for File.root?
It definitely seems like it has to do with either 1) the fact that root_id is a self-referential FK or 2) the fact that there are several self-referential FKs in File and SQLAlchemy gets confused.
Things I've tried.
Trying to define a 'root' relationship() - I think this is wrong, this should not be represented by a join.
Trying to define a 'root' column_property() - allows read access to an already set root_id property, but when assigning to it, does not get reflected back to root_id
How can I do what I'm trying to do? Thanks!
from sqlalchemy import create_engine, Column, ForeignKey, Integer, String
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import backref, relationship, scoped_session, sessionmaker, column_property
Base = declarative_base()
engine = create_engine('sqlite:///:memory:', echo=True)
Session = scoped_session(sessionmaker(bind=engine))
class Project(Base):
__tablename__ = 'projects'
id = Column(Integer, primary_key=True)
directory_id = Column(Integer, ForeignKey('files.id'))
class File(Base):
__tablename__ = 'files'
id = Column(Integer, primary_key=True)
path = Column(String)
parent_id = Column(Integer, ForeignKey('files.id'))
root_id = Column(Integer, ForeignKey('files.id'))
children = relationship('File', primaryjoin=id==parent_id, backref=backref('parent', remote_side=id), cascade='all')
Base.metadata.create_all(engine)
p = Project()
root = File()
root.path = ''
p.directory = root
f1 = File()
f1.path = 'test.txt'
f1.parent = root
f1.root = root
Session.add(f1)
Session.add(root)
Session.flush()
# do this otherwise f1 will be returned when calculating rf1
Session.expunge(f1)
rf1 = Session.query(File).filter(File.path == 'test.txt').one()
# this property does not exist
print rf1.root
My understanding is that defining a FK foo_id into table Foo implicit creates a foo attribute to which you can assign a Foo object.
No, it doesn't. In the snippet, it just looks like it is being done for Project.directory, but if you look at the SQL statements being echo'ed, there is no INSERT at all for the projects table.
So, for it to work, you need to add these two relationships:
class Project(Base):
...
directory = relationship('File', backref='projects')
class File(Base):
...
root = relationship('File', primaryjoin='File.id == File.root_id', remote_side=id)
In SQLAlchemy, we can declare tables and their relations like this:
user = Table(
'users', metadata,
Column('id', Integer, primary_key=True))
address = Table(
'adresses', metadata,
Column('id', Integer, primary_key=True),
Column('user_id', Integer, ForeignKey('user.id')))
class User(object): pass
class Address(object): pass
session.mapper(User, user, properties=dict(
'address' = relation(Address, backref='user', cascade="all")))
(Please notice the cascade relation in the line above.)
However, we can also use an alternate shorthand style, called declarative style, in which we can express the same things in fewer lines of code, omitting the mapper() relationships:
class User(Base):
__tablename__ = 'users'
id = Column(Integer, primary_key=True)
class Adress(Base):
__tablename__ = 'adresses'
id = Column(Integer, primary_key=True)
user_id = Column(Integer, ForeignKey('user.id')))
But if we use this declarative style, is there an alternative way to define cascade relationships?
Actually the use of "declarative" does not mean you omit the relationships. You still specify them, roughly the same way, but directly on the class as attributes rather than in the mapper:
class User(Base):
__tablename__ = 'users'
id = Column(Integer, primary_key=True)
address = relation('Address', backref='user', cascade='all')
class Address(Base):
__tablename__ = 'addresses'
id = Column(Integer, primary_key=True)
user_id = Column(Integer, ForeignKey('users.id'))
(Note that I've fixed the spelling of "address", in case you cut-and-paste this.)
The declarative documentation covers this. Note that in the simple cases, it figures out what foreign keys to use automatically, but you can be more explicit if required.
Also note the use of the string 'Address' since at the time I use it in the User class the related class has not yet been defined.