Since Django 1.8 the makemigrations command has a --name, -n option to specify custom name for the created migrations file.
I'd like to know whether it's safe in older versions of Django to create the migrations file with the automatically generated name and then rename the file manually. It seems to work as expected. Are there any potential risks?
This works, with a minor caveat: Django will no longer know that the renamed migration is applied.
So the steps to renaming a migration are:
Rename the file.
Repoint any dependencies to the new file.
If the renamed migration was already applied, apply it again using --fake.
If it's a brand new migration, 2 and 3 won't apply, and it's perfectly fine to rename them.
This is happens in Django every time migrations are squashed. A new file is generated thats contains the class variable replaces, this lists the migration files that are being replaced.
So to rename a file migration file add in the following variable in the Migration class:
replaces = [('app name', 'migration file name'), ]
And everything works like it did before the file change.
Related
The following characters are forbidden in Windows file names:
< > : " / \ | ? *
In our Git repo, an old migration file "0012_iosversion_iosversion_recommended_>_obsolete.py" is keeping a colleague from cloning the repo. Django auto-generated this file from a model's following:
class Meta:
constraints = [CheckConstraint(
check = Q(recommended__gt=F('obsolete')),
name = 'recommended_>_obsolete'
)]
#12 is not a necessary check we need, however we have 3 newer migrations on top of #12 that create new tables that are currently in use. What is the best practice to rename or remove the file?
Can we regenerate all of the migration files in a window safe way
Can we rename the file?
Rollback all of the changes and drop our tables?
I have a Django app hosted on Heroku. In it, I am using a view written in LaTeX to generate a pdf on-the-fly, and have installed the Heroku LaTeX buildpack to get this to work. My LaTeX view is below.
def pdf(request):
context = {}
template = get_template('cv/cv.tex')
rendered_tpl = template.render(context).encode('utf-8')
with tempfile.TemporaryDirectory() as tempdir:
process = Popen(
['pdflatex', '-output-directory', tempdir],
stdin=PIPE,
stdout=PIPE,
)
out, err = process.communicate(rendered_tpl)
with open(os.path.join(tempdir, 'texput.pdf'), 'rb') as f:
pdf = f.read()
r = HttpResponse(content_type='application/pdf')
r.write(pdf)
return r
This works fine when I use one of the existing document classes in cv.tex (eg. \documentclass{article}), but I would like to use a custom one, called res. Ordinarily I believe there are two options for using a custom class.
Place the class file (res.cls, in this case) in the same folder as the .tex file. For me, that would be in the templates folder of my app. I have tried this, but pdflatex cannot find the class file. (Presumably because it is not running in the templates folder, but in a temporary directory? Would there be a way to copy the class file to the temporary directory?)
Place the class file inside another folder with the structure localtexmf/tex/latex/res.cls, and make pdflatex aware of it using the method outlined in the answer to this question. I've tried running the CLI instructions on Heroku using heroku run bash, but it does not recognise initexmf, and I'm not entirely sure how to specify a relevant directory.
How can I tell pdflatex where to find to find the class file?
Just 2 ideas, I don't know if it'll solve your problems.
First, try to put your localtexmf folder in ~/texmf which is the default local folder in Linux systems (I don't know much about Heroku but it's mostly Linux systems, right?).
Second, instead of using initexmf, I usually use texhash, it may be available on your system?
I ended up finding another workaround to achieve my goal, but the most straightforward solution I found would be to change TEXMFHOME at runtime, for example...
TEXMFHOME=/d pdflatex <filename>.tex
...if you had /d/tex/latex/res/res.cls.
Credit goes to cfr on tex.stackexchange.com for the suggestion.
I have a Django model with
...
image = models.ImageField(default=None, upload_to=settings.PHOTO_UPLOAD_TO)
...
I have changed the value of settings.PHOTO_UPLOAD_TO, but the files have remained where they were, and the database entries also don't seem to have changed. A newly added image is placed in the correct new location, but not the old ones. Is it an expected behaviour? Is there a way to migrate the image locations? I would like to slightly change the directory/URL structure of my project.
The path of a FileField/ImageField is stored relative to MEDIA_ROOT, so if you want to move the files to the new upload_to folder, you're gonna need to put that in your migration yourself (like you suggested).
I made the clumsiest mistake. When I went to highlight a migration file's name in my text editor, my finger slipped and I deleted that migration file. The schema already has the migration file's table schema, but how do I restore the file I just deleted? I found this SO post, but it did not help me.
I've been blowing through some work so I did not commit and cannot reclaim the lost file via version control.
Ok this solved my problem. I wrote, git diff, in terminal where was printed the name of the file I deleted: 20151014152222_create_post_categories.rb
I just recreated this file with the appropriate migration code in it. Originally I wanted to rename the table to, posts_categories, so after running rake db migrate, I ran, rake db:migrate:down VERSION=20151014152222, renamed the file and the first argument to, create_table, with :posts_categories.
Then I just ran the migrations again. This obviously brought back the missing file and correctly edited my schema.
I am trying to add a few new columns to certain tables in Joomla, since i need to migrate these fixes from dev to production i am trying to do this the clean way, updates trough the filesystem.
I have followed a few tutorials concerning this and did the following.
I created the folder updates/sql and put a new sql file in it with my new version (1.5).
I changed the version number in my xml file.
I refreshed my cache in the backend.
Here are the codes I used:
My version:
<version>1.5</version>
The update node:
<update>
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
<schemapath type="sqlsrv">sql/updates/sqlsrv</schemapath>
<schemapath type="sqlazure">sql/updates/sqlazure</schemapath>
</schemas>
</update>
The sql file:
ALTER TABLE `#__mycomponent` ADD `field` VARCHAR(255);
I tested my query directly against the database and it worked, what am I missing?
Short answer - Joomla!'s DB migration tool only does them after uploading a new component via the Component Manager. It doesn't check for a migration on every $_REQUEST, which is what your question suggests.
Longer Answer
Make sure you run the upgrade via the component manager. Simply over-writing the files doesn't trigger Joomla's migration process. Check the #__schemas table for your component's ID, and it'll have a corresponding database schema version #. If that version hasn't incremented yet, then the migration wasn't applied.
Part of the problem is
I am trying to do this the clean way, updates trough the filesystem
While I agree with you, that would be the clean way: Joomla! wants you to do things the Joomla! way ;-)
Important Note about Joomla! SQL Files
SQL files cannot contain C style comments (# comment here), and must contain comments like this -- comment here Spent a few hours debugging my own code, and had to re-run an upgrade about 25 times to figure out where the database schema migration was failing.
Comments may support the /* Comment */ style syntax, but I have yet to test that as extensively. YMMV.