I am using a postgresql database. I am updating a certain field of an existing database row and saving it again. However, this is change not reflecting inside the database (viewing it on DBeaver). The bizarre thing is that the change is properly reflected using the debugger and querying the database with the same ID.
p_details: ProjectDetails = ProjectDetails.objects.get(pk=res['id'])
p_details.build_status = ProjectBuildEnums.PASSED.value if res['error'] is None else ProjectBuildEnums.FAILED.value
p_details.build_error = json.dumps(res)
p_details.save(update_fields=["build_status", "build_error"])
sleep(1)
new_p = ProjectDetails.objects.get(pk=res['id'])
This is the line of code where I am updating the database. After the save, I am requerying the database using the same primary key ID. At this instance, using the debugger, I can see the changes clearly. However, viewing this database using DBeaver after refreshing the database doesnt show this change yet. Once the view is complete, and I refresh the database again, this change is still not present, meaning the update has disappeared. Does anyone know what is going on? After the above lines, the ProjectDetails database is no longer being touched. No errors are shown in the terminal/debugger either.
Related
We have a potential race condition where multiple users can try to create or update a record. Wondering if there's a way to create a column, than when set (to say true), then an exception will be thrown, preventing the update.
The underlying database is postgres, but since we're using django to wrap it, we would like to limit ourselves to something django offers, and not mess with very specific database settings. Thanks!
I'm listing a hasMany relationship, of which a record can be updated, deleted or added.
I want to provide the user with a revert option, which should revert the list to its last saved state.
For deletion, I do item.deleteRecord(), so that I can revert the changes using rollbackAttributes(). Changes are reverted as expected, but it behaves inconsistently while saving (saving the model to which the items belong doesn't update its dirty state on first save, next record disappears from the view though the changes sent to the back-end properly, and so on).
So I decided to use unloadRecord, but once a record is unloaded, I'm unable to revert it without reloading the page.
One way would be to save the old state and use it on revert. Please help me with a cleaner to achieve this.
For an idea of my model, Ember: Model's property changes not detected in computed property
Unloading a record removes it from Ember Data’s in-memory data store.
The only way to get that record back, is by re-requesting it from the server, aka: this.store.findRecord().
You’ll get a fresh copy from the server, but that won’t have any changes the client made before it was unloaded, and may have new changes from other clients.
We have django-simple-history set up for our models. Recently a whole bunch of models were mysteriously deleted. This was noticed a few days after the fact, so it would be nice to avoid a full DB backup restore since that would wipe manual changes that happened after the fact.
I cannot find any way to easily restore an model instance, specifically a deleted one. I can query the Historical version of the model and find everything that was deleted. With that I can also observe that all of them had deletions as their last change. I can use the instance property on history - 1 to get the state before deletion but if I try to save that it errors since the model instance was deleted and doesn't exist anymore.
So basically, what is the cleanest way to restore a deleted model instance if I have the Historical record of it with django-simple-history? I would like to retain the history if possible, so I am looking into any solution before totally recreating the objects.
As I understand, the question, it is about restoring a deleted model instance, not the class itself. So Kal's answer does not help here.
To restore a deleted instance, simple history can NOT be used. According to the documentation, simple history can only restore model instances that are still existing.
Since you have a full backup of the database, you can import this database into the django environment, load the old model instance from this backup database and save it to the production database (choose the database in django shell with "using"). See this post.
The best way to avoid such situations is to use the app "reversion". With this django-app, you actually can restore deleted instances. See the documentation.
Do you mean that your model, not just the instances, has been completely deleted? If that’s the case, it probably means some migration removed it.
You could try reverting the migration then restore from the Historical record.
The previous version of your model is stored in the _HISTORICAL<model_name> table. You could do a simple sql insert/select query to copy the data from that table back into the original table. Something like the below would work, but check the correct sql syntax for your database.
insert into app_mymodel (col_a, col_b)
select col_a, col_b from app_HISTORICALmymodel
where id in (1,2,3...)
If model using django-simple-history then,
Data can be restored from the historical model.
We need to filter from the historical model. for eg with some keyword or in some date range in which period the data got deleted accidentally.
For eg. the Model Name is Car, then by default django-simple-history creates a historical model as HistoricalCar.
historical_data = HistoricalCar.objects.filter(history_type='-')
for each in historical_data:
instance = each.instance # This return instance of car.
instance.pk = None # Create New Instance
instance.save()
After recovering from a recent hardware failure on our SharePoint server (single server farm), all the SQL DBs were in suspect mode, to change the mode back to normal, we ran the consistency checks on all DBs and successfully changed back to normal mode. However, one particular database i.e. SharePoint_AdminContent_ is still causing SQL crashes with messages like:
The Database ID 6, Page (1:11812), slot 22 for LOB data type node does not exist. This is usually caused by transactions that can read uncommitted data on a data page. Run DBCC CHECKTABLE.
dbcc checkdb with REPAIR_ALLOW_DATA_LOSS fails and does not complete successfully.
I have set the DB to single user mode for now, the central admin works when I set to multi user mode but the SQL logs very quickly fill up the hard drive with crash dumps. I suspect that the hardware failure has caused some serious damage to the DB which cannot be repaired.
I tried to move central admin site to a new content db using move-spsite but it fails with the error given above.
Now, in an attempt to repair central admin, I have tried to unprovision the central admin and tried to re-create the central admin using both Configuration Wizard GUI and PowerShell, one by one but both these methods return the same error that I have specified above, while trying to create new central admin.
I have tried to backup the corrupted DB and restore it to a new DB to see if it works, but it does not. The corruption transfers to restored DB as well.
I have also tried to detach the corrupted AdminContent DB from SQL and then tried to create a new central admin site (hoping that it will create a new admin content DB) but it complains that it cannot find the old admin content db (I suppose SharePoint_Config DB holds the references to old AdminContent DB), anyways this method fails as well because the old DB detached, and is not available.
Then, I have tried to create a new content database under central admin web application, unprovisioned central admin site, removed corrupted AdminContent DB (through central admin) and tried to create new central admin site using psconfiggui, it did not open the site until I attached corrupted admin content DB through powershell (mount-spcontentdatabase)
I have a full farm backup taken using SharePoint native tools through powershell. It has central admin backup but it cannot be restored individually, I will need to restore the whole farm somewhere to even try to see if restored admin content DB will work and even if it works, how would I transfer it back to original farm because it will have a new guid and how would I associate it with original farm? I cannot restore it to original farm because the backup is 3-4 days older and I can only restore admincontent if I perform a full farm restore which will overwrite all the content as well.
Is there any way I can setup a new Admin Content DB and create a new central admin site using that DB? or anything I can do to fix this? Any help will be appreciated.
After 7 months you probably fixed it, on that case please share your approach with us, otherwise let me recommend you to have a look on:
http://www.sqlskills.com/blogs/paul/finding-table-name-page-id/
Particularly on this clause and how to read its output:
DBCC PAGE (6, 1, 11812, 0) WITH TABLERESULTS;
Note: The article's author is Paul Randal.
I just tested it myself. I had Django models, and there have already been instances of the models in the database.
Then I added a dummy integer field to a model and ran manage.py syncdb. Checked the database, and nothing happened to the table. I don't see the extra field added in.
Is this the expected behavior? What's the proper way of modifying the model, and how will that alter the data that's already in the database?
Django will not alter already existing tables, they even say so in the documentation. The reason for this is that django can not guarantee that there will be no information lost.
You have two options if you want to change existing tables. Either drop them and run syncdb again, but you will need to store your data somehow if you want to keep it. The other options is to use a migrations tool to do this for you. Django can show you the SQL for the new database schema and you can diff that to the current version of the database to create the update script.
You could even update your database mannually if it is a small change and you don't want to bother with migrations tools, though I would recommend to use one.
Please use south for any kind of changes to get reflected to your database tables,
here goes the link for using south
Link for South documentation