Migrating Django TextChoices to IntegerChoices - django

In Django (3.2.8), I have a set of TextChoices, which I would like to change to IntegerChoices. I will keep the keys the same, just the values in the database stored will just differ. I do this for consistency and I'm fixing some legacy code.
Naturally, I changed the TextChoices to IntegerChoices, and the corresponding field to an IntegerField. As expected however, upon migrating, I get a django.db.utils.DataError: invalid input syntax for type integer: "option1". I feel like there should be a way that I can define a mapping for this migration to happen, but wasn't able to find any documentation on this.

Related

what way can i fix django DB migration error without deleting migration files

what is the best way to fix this kind of DataBase Errors without having to delete my db and migration files and starting to enter data from scratch?
django.db.utils.IntegrityError: The row in table 'store_product_category' with primary key '1' has an invalid foreign key: store_product_category.category_id contains a value '1' that does not have a corresponding value in store_category.id.
while inspection the sqlit DB i observe that there is a mismatch in the IDs of the store_product_category and store_category.id.
is there anyway i can modify the id directly on the DB, i dont want to start deleting database files and migrations
If I've understood right:
The model StoreProductCategory has a FK - category, linking to a model StoreCategory.
You have a SPC record with category == 1 but no record in StoreCategory with this ID?
If so, the fix is reasonably simple.
Enter the DB shell using python manage.py dbshell and run an SQL INSERT command to add the appropriate record.
Change your model for StoreProductCategory and set on_delete for that FK. I would suggest maybe PROTECT might be appropriate here, but it's up to you - just make sure it's something that will keep things consistent.
If (2) is already done, I do question how this happened in the first place - that would kind of indicate somebody has messed directly with the DB. You may want to investigate who has access and what gets done there.

How to check if a CRecordset field has already been fetched?

I'm using a CDatabase*/CRecordset* duo to read a HFSQL (windev) database through an ODBC DSN.
There are many issues with HFSQL's handling of binary blobs, especially when they're empty.
One such problem causes my app to fire warnings and exceptions on loop as I read a table. I use a custom class that manages the recordset and fetches every field once, in ascending ordinal order, and stores the resulting CDBVariant vars in a vector for my own later uses. The error I get alternates between Warning: ODBC Success With Info on field 8. when the field has content and Error: GetFieldValue operation failed on field 8. Data already fetched for this field. when it has none. Clearly, I have not fetched the field before, so either the wrong error message is displayed or the CRecordset believes it is correct and I should be able to detect it beforehand.
How could I go about detecting whether my CRecordset considers a field to have already been fetched? GetODBCFieldInfo does not give me any useful information, have I missed something?

unique=True gives already exist! Even if interchanging the values of two objects

To display objects (members) in particular order, I have made a field, order:
order = models.IntegerField(unique=True,null=True,blank=True)
so that I can do an .order_by('order') to get the required order.
In Django Admin, the table has only two objects with order 0,1. If I want to interchange it by 1,0 I get an error:
About us with this Order already exists
For ease of using Django admin, is there a better method to achieve the above?
You can remove unique=True and add a custom action to reorder objects. In this form, Django admin applies each object in a separate transaction and it causes this error. You may override the update function of your admin class and do all changes in a bulk-update transaction like this. But I don't recommend it. Because you may make a mistake in the future and want to edit other fields and this line makes a bug.

How to limit columns returned by Django query?

That seems simple enough, but all Django Queries seems to be 'SELECT *'
How do I build a query returning only a subset of fields ?
In Django 1.1 onwards, you can use defer('col1', 'col2') to exclude columns from the query, or only('col1', 'col2') to only get a specific set of columns. See the documentation.
values does something slightly different - it only gets the columns you specify, but it returns a list of dictionaries rather than a set of model instances.
Append a .values("column1", "column2", ...) to your query
The accepted answer advising defer and only which the docs discourage in most cases.
only use defer() when you cannot, at queryset load time, determine if you will need the extra fields or not. If you are frequently loading and using a particular subset of your data, the best choice you can make is to normalize your models and put the non-loaded data into a separate model (and database table). If the columns must stay in the one table for some reason, create a model with Meta.managed = False (see the managed attribute documentation) containing just the fields you normally need to load and use that where you might otherwise call defer(). This makes your code more explicit to the reader, is slightly faster and consumes a little less memory in the Python process.

Django Dynamic Forms Save

I am using James Bennetts code (link text) to create a dynamic form. Everything is working ok but I have now come to the point where I need to save the data and have become a bit stuck. I know I can assess the data returned by the form and simply save this to the database as a string but what I'd really like to do is save what type of data it is e.g. date, integer, varchar along with the value so that when it comes to viewing the data I can do some processing on it depending on what type it is e.g. get dates greater than last week.
So my question is how do I access what database type the form element is based on what type of form element it is e.g. a django.forms.IntegerField has a database field type of int, django.forms.DateField would be a date field and django.forms.ChoiceField would be a varchar field?
Why do you want to know, what kind of database field you are using? Are you storing information from the form through raw sql? You should have some model, that you are storing information from the form and it will do all the work for you.
Maybe you could show some form code? Right now it's hard to determine, what exactly you are trying to do.
I can not understand the exact problem, so forgive me if I get things wrong.
If you are using models, then you don't need to know about database-level data types. They are defined by django according to your model fields.
However, since you are talking about dynamic forms (I've read the article), you are probably not working with models, at least not directly. In that case, it should not matter as well, because you are using form validation so, for example, you can be absolutely sure that an integer comes out of a forms.IntegerField field, unicode comes out of forms.CharField and so on.
If you are writing your database-interaction routies by hand (raw sql), then you have to map python-types to db-types yourself, for example <type 'int'> goes to a column of type integer (or something), <type 'datetime.datetime'> goes to a datetime type of column (or not, this example is arbitrary) and so on. When you are using models, django does this type of mapping for you in a database-engine-independent way.
Either way, you, yourself are defining the datatypes on the python side and you or django must also define the datatypes on the db side. The choice of those types is, at times, not an automatic 1:1 type of decision, but, rather, a design decision, based on what this data is used for in your application.
Sorry, if this makes little sense, but, I must admit, that I don't quite understand the problem behind your question.
If you're using James' code, then you don't get a Model out of the form per se, rather a list of form field elements. That means that you can't save the data as a Model instance.
I think you have two choices; bundle the whole form into a JSON object and save that into a LONGTEXT variable in your database, or save each form element into a row of the database on its own, saving it into a BLOB entry. In this case, you'll need to 'pickle' the object before saving it. If you pickle the object and save it into the database, when you retrieve it and unpickle it, you'll have all the python class information associated with the object.
Trying to make this clearer - if you have the bytes; 2009-11-28 21:34:36.516176, is this a str or a datetime object? You can't tell if it's stored in the database as a VARCHAR or LONGTEXT. Which is the core of your question - you do get object information if you save it as a pickled object though.
By extension, you could save your whole Form object into the database, either as a JSON object, or pickle the object and save that.
I'm struggling with something very similar at the moment, as I'm trying to put together a dynamic form system, and thinking of going the 'individual form field element, pickled' and then saved into the database. So I'll be watching how this question works out! :)