Dear Jason
db per project/app: Okay, I will keep that in mind for the future. I just
thought that it would be a cleaner way when each db and app would serve a
single purpose
logging: I am sorry, but I have to ask again, where do I put that what you
wrote ( logger.info("db does not match db app name"), or raise
Exception("db does not match app name"))? Does this belong in the router.py
or migration file or another place?
Best regards
Martin
On Wednesday, April 5, 2023 at 9:40:27 PM UTC+2 Jason wrote:
> ahhh, no not at all. One db per project, yes. Application, no. That's
> really expanding complexity. If you need that requirement, that's one
> thing, but its something you really should have an explicit requirement for
> before designing.
>
> As far as the second question, no not at all. Just add logging there, or
> raise an exception
>
> ie, logger.info("db does not match db app name"), or raise Exception("db
> does not match app name")
>
> On Wednesday, April 5, 2023 at 12:45:01 PM UTC-4 Martin Heitmann wrote:
>
>> Dear Jason
>>
>> Thanks for all your effort.
>>
>> Yes, I have one db per application. Isn't that a way to keep the
>> databases clean and strictly focused on one purpose? Thought that that
>> would be a good idea. Regarding the router.py: It worked for quite a while,
>> but I am not sure if I made changes to it previous to the first occurence
>> of the problem. But should it not work when every router has an entry like
>> this:
>>
>> def allow_migrate(self, db, app_label, model_name=None, **hints):
>> if app_label == 'app_name':
>> return db == 'db_app_name'
>> return None
>>
>> You wrote "What happens when you put some logging there, or raise an
>> exception on None/False? ". I would love to do that but I do not know,
>> where I must put that. I guess I must find some place in the code that
>> calls allow_migrate and check what the return value is, right?
>>
>> On Wednesday, April 5, 2023 at 12:54:58 PM UTC+2 Jason wrote:
>>
>>> so, for your original boolean migration,
>>>
>>> https://code.djangoproject.com/ticket/470
>>>
>>> https://stackoverflow.com/questions/32280343/default-value-of-djangos-model-doesnt-appear-in-sql
>>>
>>> Adding a default value doesn't go to SQL, although there's work in the
>>> django ticket above. So its inserted via app code and the original
>>> question might have been a red herring and the actual issue is your
>>> CreateModel is never applied.
>>>
>>> ouch, you have one db per application? that could likely be it, when
>>> was this routing put in place? Did it exist before the last working
>>> migration on this project? Reason I ask,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *python3 manage.py sqlmigrate ObjPLW2 0037 --database=db_obj_plw2----
>>> Create model Wartungsarbeit--CREATE TABLE `ObjPLW2_wartungsarbeit` (`id`
>>> integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `wa_titel` varchar(201) NOT
>>> NULL, `wa_beschreibung` longtext NOT NULL, `wa_turnus` integer UNSIGNED NOT
>>> NULL CHECK (`wa_turnus` >= 0), `wa_startdatum` date NOT NULL,
>>> `wa_erstelldatum` datetime(6) NOT NULL, `wa_bearbeitungsdatum` datetime(6)
>>> NOT NULL);*
>>>
>>> is vaid SQL and that's what django would send to your db. So if its not
>>> being applied, the allow_migrate might be at cause here. What happens when
>>> you put some logging there, or raise an exception on None/False? The docs
>>> at
>>> https://docs.djangoproject.com/en/4.1/topics/db/multi-db/#allow_migrate
>>> state
>>>
>>>
>>> *makemigrations always creates migrations for model changes, but if
>>> allow_migrate() returns False, any migration operations for the model_name
>>> will be silently skipped when running migrate on the db. *
>>>
>>>
>>> On Wednesday, April 5, 2023 at 1:52:12 AM UTC-4 Martin Heitmann wrote:
>>>
>>>> Dear Jason
>>>>
>>>> Thanks for your reply. I am not absolulety sure what this question
>>>> means "What specifically was the changeset occurring and what isn't? ",
>>>> but
>>>> I try to answer it the best way I can. I worked on the app quite a while
>>>> ago and back then everything seemed to work. As far as I can understand my
>>>> own steps back then I tried to alter only one field.
>>>>
>>>> extract from migrations file:
>>>> migrations.AlterField(
>>>> model_name='waeschepaket',
>>>> name='w_bezahlt',
>>>> field=models.BooleanField(choices=[(False, 'Nein'), (True,
>>>> 'Ja')], default=False),
>>>> ),
>>>>
>>>> Here is a small screenshot from phpmyadmin
>>>> [image: field.png]
>>>> I guess that if that field alteration would have worked than the
>>>> default value should be False or something else but not None.
>>>>
>>>> Then I guess that I forgot about it and just worked with app as it was
>>>> for more than a year and now I wanted to add a new model:
>>>>
>>>> operations = [
>>>> migrations.CreateModel(
>>>> name='Wartungsarbeit',
>>>> fields=[
>>>> ('id', models.AutoField(auto_created=True,
>>>> primary_key=True, serialize=False, verbose_name='ID')),
>>>> ('wa_titel', models.CharField(max_length=201)),
>>>> ('wa_beschreibung', models.TextField()),
>>>> ('wa_turnus', models.PositiveIntegerField(default=1)),
>>>> ('wa_startdatum',
>>>> models.DateField(default=django.utils.timezone.now)),
>>>> ('wa_erstelldatum',
>>>> models.DateTimeField(auto_now_add=True)),
>>>> ('wa_bearbeitungsdatum',
>>>> models.DateTimeField(auto_now=True)),
>>>> ],
>>>> ),
>>>>
>>>> But this does not show up in any way. During the last weeks I have
>>>> tried a lot of things that I read on the web and I am afraid that I may
>>>> have made a mess. There were many instructions about inspectdb,
>>>> --fake-initial, removing the app-specific entries from the table
>>>> django_migrations and so on. But nothing of that worked. Now I am at a
>>>> point where I merged the last two, obviously not working migrations into
>>>> one, which is currently the 37th for this app.
>>>>
>>>> As I already have a lot of content in the database I don't want to
>>>> loose that and instead I search for a way to start fresh and get rid of
>>>> that error. And if possible I would like to know where that error
>>>> originated. But currently I am at my wits end. First I thought that it
>>>> must
>>>> have to do with the database access, but then the app would not work and
>>>> other content could not be entered and changed and so on. I checked my
>>>> privileges via phpmyadmin. Everything is fine there, too. And of course
>>>> the
>>>> app is in INSTALLED_APPS, otherwise it would not work as well. One more
>>>> thing that I am not sure of is the database routing. I have a router.py
>>>> and
>>>> there I have pretty much the same entries for all apps. Looks similar to
>>>> this:
>>>>
>>>> def allow_migrate(self, db, app_label, model_name=None, **hints):
>>>> if app_label == 'app_name':
>>>> return db == 'db_app_name'
>>>> return None
>>>>
>>>> I don't know if this can be relevant for this problem.
>>>>
>>>> @Jason: Could I answer your questions?
>>>>
>>>> Best regards
>>>> Martin
>>>> On Tuesday, April 4, 2023 at 1:21:50 PM UTC+2 Jason wrote:
>>>>
>>>>> What specifically was the changeset occurring and what isn't? Is the
>>>>> model being created in the db, or is it the field change that's not
>>>>> replicating? In your comments, you showed just one migration, but seems
>>>>> from additional comments you made, there are two or more? What are they,
>>>>> specifically. And what is the model field change you're making?
>>>>>
>>>>> As mentioned earlier, django model field changes do not always equate
>>>>> to a migration for that model. So django made a migration for your
>>>>> model,
>>>>> but might also be an empty/no op one for your field change
>>>>> On Tuesday, April 4, 2023 at 2:53:22 AM UTC-4 Martin Heitmann wrote:
>>>>>
>>>>>> Would you recommend using inspectdb?
>>>>>>
>>>>>> On Monday, April 3, 2023 at 1:58:55 PM UTC+2 Martin Heitmann wrote:
>>>>>>
>>>>>>> Dear Jason
>>>>>>>
>>>>>>> What could I do to get it back in sync? I tried several
>>>>>>> recommendations from the web, but perhaps the devil is in the details.
>>>>>>> If
>>>>>>> someone could tell me which steps I should take, I would gladly roll
>>>>>>> back
>>>>>>> the migrations and sync it again. And I would like to share the output.
>>>>>>> However, I have the existing database and may not loose the existing
>>>>>>> content.
>>>>>>>
>>>>>>> As it seems to me I wanted to change a field more than a year ago.
>>>>>>> Perhaps that did not work. I do not remember. And now I wanted to add a
>>>>>>> new
>>>>>>> model to the app.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Martin
>>>>>>>
>>>>>>> On Monday, April 3, 2023 at 12:59:50 PM UTC+2 Jason wrote:
>>>>>>>
>>>>>>>> this is all a pretty weird experience, I have to say. One thing
>>>>>>>> that is suggesting to me that your migration history is.out of sync is
>>>>>>>> that
>>>>>>>> migration you shared earlier is not what I would expect an addField
>>>>>>>> operation, not a CreateModel.
>>>>>>>>
>>>>>>>> Also, django migrations are required when model changes, but not
>>>>>>>> all model changes require emitting SQL. What exactly is the change
>>>>>>>> you're
>>>>>>>> expecting to see? What field, what was it before, and what do you want
>>>>>>>> it
>>>>>>>> to go to?
>>>>>>>>
>>>>>>>> On Sunday, April 2, 2023 at 3:43:27 PM UTC-4 Martin Heitmann wrote:
>>>>>>>>
>>>>>>>>> A little PS: I logged in via phpmyadmin and saw that my user has
>>>>>>>>> all privileges. So this should not be the source of the problem.
>>>>>>>>>
>>>>>>>>> On Saturday, April 1, 2023 at 8:07:57 PM UTC+2 Martin Heitmann
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I have a little update, but not a solution. Adding the database
>>>>>>>>>> to sqlmigrate will give me the SQL command, but nothing more:
>>>>>>>>>>
>>>>>>>>>> python3 manage.py sqlmigrate ObjPLW2 0037 --database=db_obj_plw2
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> -- Create model Wartungsarbeit
>>>>>>>>>> --
>>>>>>>>>> CREATE TABLE `ObjPLW2_wartungsarbeit` (`id` integer
>>>>>>>>>> AUTO_INCREMENT NOT NULL PRIMARY KEY, `wa_titel` varchar(201) NOT
>>>>>>>>>> NULL,
>>>>>>>>>> `wa_beschreibung` longtext NOT NULL, `wa_turnus` integer UNSIGNED
>>>>>>>>>> NOT NULL
>>>>>>>>>> CHECK (`wa_turnus` >= 0), `wa_startdatum` date NOT NULL,
>>>>>>>>>> `wa_erstelldatum`
>>>>>>>>>> datetime(6) NOT NULL, `wa_bearbeitungsdatum` datetime(6) NOT NULL);
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> -- Alter field w_bezahlt on waeschepaket
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> And for whatever reason it includes only the table creation and
>>>>>>>>>> not the change in the other field.
>>>>>>>>>> On Saturday, April 1, 2023 at 7:46:51 PM UTC+2 Martin Heitmann
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Dear Jason
>>>>>>>>>>>
>>>>>>>>>>> I went two migration steps back, then again I did makemigrations
>>>>>>>>>>> and then I went for sqlmigrate. This was the output:
>>>>>>>>>>> python3 manage.py sqlmigrate ObjPLW2 0037
>>>>>>>>>>> --
>>>>>>>>>>> -- Create model Wartungsarbeit
>>>>>>>>>>> --
>>>>>>>>>>> --
>>>>>>>>>>> -- Alter field w_bezahlt on waeschepaket
>>>>>>>>>>> --
>>>>>>>>>>> It does not include any SQL.
>>>>>>>>>>>
>>>>>>>>>>> Does anyone know where this is no SQL in the output?
>>>>>>>>>>>
>>>>>>>>>>> On Saturday, April 1, 2023 at 3:46:41 PM UTC+2 Martin Heitmann
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Dear Jason
>>>>>>>>>>>> Thanks for your reply. I will gladly do that. This is the
>>>>>>>>>>>> latest migration file:
>>>>>>>>>>>>
>>>>>>>>>>>> # Generated by Django 3.2.10 on 2023-04-01 13:45
>>>>>>>>>>>>
>>>>>>>>>>>> from django.db import migrations, models
>>>>>>>>>>>> import django.utils.timezone
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> class Migration(migrations.Migration):
>>>>>>>>>>>>
>>>>>>>>>>>> dependencies = [
>>>>>>>>>>>> ('ObjPLW2', '0037_alter_waeschepaket_w_bezahlt'),
>>>>>>>>>>>> ]
>>>>>>>>>>>>
>>>>>>>>>>>> operations = [
>>>>>>>>>>>> migrations.CreateModel(
>>>>>>>>>>>> name='Wartungsarbeit',
>>>>>>>>>>>> fields=[
>>>>>>>>>>>> ('id', models.AutoField(auto_created=True,
>>>>>>>>>>>> primary_key=True, serialize=False, verbose_name='ID')),
>>>>>>>>>>>> ('wa_titel', models.CharField(max_length=201)),
>>>>>>>>>>>> ('wa_beschreibung', models.TextField()),
>>>>>>>>>>>> ('wa_turnus',
>>>>>>>>>>>> models.PositiveIntegerField(default=1)),
>>>>>>>>>>>> ('wa_startdatum',
>>>>>>>>>>>> models.DateField(default=django.utils.timezone.now)),
>>>>>>>>>>>> ('wa_erstelldatum',
>>>>>>>>>>>> models.DateTimeField(auto_now_add=True)),
>>>>>>>>>>>> ('wa_bearbeitungsdatum',
>>>>>>>>>>>> models.DateTimeField(auto_now=True)),
>>>>>>>>>>>> ],
>>>>>>>>>>>> ),
>>>>>>>>>>>> ]
>>>>>>>>>>>>
>>>>>>>>>>>> Does this help?
>>>>>>>>>>>> On Saturday, April 1, 2023 at 1:55:00 PM UTC+2 Jason wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> part of getting effective help is sharing how you're doing
>>>>>>>>>>>>> things and the code. for example, sharing the migration
>>>>>>>>>>>>> generated would be
>>>>>>>>>>>>> helpful. you do have the context of how and what is being
>>>>>>>>>>>>> executed, we
>>>>>>>>>>>>> don't, so sharing that with your original questions is a big part
>>>>>>>>>>>>> in
>>>>>>>>>>>>> getting effective help
>>>>>>>>>>>>> On Saturday, April 1, 2023 at 4:08:06 AM UTC-4 Martin Heitmann
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The migrations do not show up in the django_mirations table.
>>>>>>>>>>>>>> The problem must occur earlier.
>>>>>>>>>>>>>> On Saturday, April 1, 2023 at 8:42:20 AM UTC+2 David Nugent
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would check in the django_migrations table to ensure that
>>>>>>>>>>>>>>> the migration has successfully been run.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From: 'Martin Heitmann' via Django users
>>>>>>>>>>>>>>> <django...@googlegroups.com>
>>>>>>>>>>>>>>> Reply: django...@googlegroups.com
>>>>>>>>>>>>>>> <django...@googlegroups.com>
>>>>>>>>>>>>>>> Date: 31 March 2023 at 19:46:02
>>>>>>>>>>>>>>> To: Django users <django...@googlegroups.com>
>>>>>>>>>>>>>>> Subject: Migration running in shell, but no change in DB
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello everyone
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have a project with multiple apps in it. As database I
>>>>>>>>>>>>>>>> use MariaDB. Have not touched it for a while, but now I had to
>>>>>>>>>>>>>>>> add a field
>>>>>>>>>>>>>>>> to the models of one app. makemigrations and migrate run
>>>>>>>>>>>>>>>> without any
>>>>>>>>>>>>>>>> indication of an error. But no change occurs in the db. Tested
>>>>>>>>>>>>>>>> it with an
>>>>>>>>>>>>>>>> altered models.py in another app and the result is the same.
>>>>>>>>>>>>>>>> Do you have
>>>>>>>>>>>>>>>> any advice how to narrow this down?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>>>>> Martin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>>>> Google Groups "Django users" group.
>>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails
>>>>>>>>>>>>>>>> from it, send an email to django-users...@googlegroups.com.
>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>> https://groups.google.com/d/msgid/django-users/be9ef414-4b51-4072-a1b7-b7ba036016aan%40googlegroups.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/django-users/be9ef414-4b51-4072-a1b7-b7ba036016aan%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/5aaeec37-7aad-4034-b241-e3c35004ef19n%40googlegroups.com.
