First time here? Check out the FAQ!
2

adding a new text field to question

I am planning to add a new (optional) text field (with a single line textbox and at most 200 characters) to "the question" in askbot code. Please point me to files that need to be changed and other required steps (like database migration etc.,).

kintali's avatar
141
kintali
asked 2012-06-12 14:54:34 -0500
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

2

To make things simpler, create a model related to thread via foreign key and maintain it in the separate app, and have migrations for that app separately. That way it will be much easier to maintain your version and avoid clashes in the migrations.

The question model is askbot.models.Thread. There is also model askbot.model.Post, which contains all comment, answer and question bodies. Thread holds the question title, tags and some more things.

Evgeny's avatar
13.2k
Evgeny
answered 2012-06-12 15:00:20 -0500
edit flag offensive 0 remove flag delete link

Comments

Thanks Evgeny.

kintali's avatar kintali (2012-06-12 15:38:28 -0500) edit

Is there any painless way to link the related model to askbot.models.Thread, I'm trying to avoid hacking the source but I can't seem to be able to extend question functionality without doing so.

shano's avatar shano (2013-08-15 04:09:08 -0500) edit

Maybe create a model and add Thread as foreign key with the related_name ? This way you won't need to modify any of the Askbot code.

Evgeny's avatar Evgeny (2013-08-15 04:15:17 -0500) edit

That could work, but it would mean a many-to-one relationship in the wrong direction. I could potentially create a m2m relationship but that's not ideal. I'm adding locations as a form of required tag and anticipated this would need a new model attached to threads, I might look into seeing if I can work this feature into tags itself.

shano's avatar shano (2013-08-15 04:35:16 -0500) edit

You can add one-to-one if you want or add a unique together constraint on ids or use ManyToMany. However I would not recommend M2M unless you really need it as database lookups will be less efficient. You could also just fork the code and add your field or add a field with migration from the additional app. If you just need one field, adding it directly will be the most efficient, but requires changes in the base schema.

Evgeny's avatar Evgeny (2013-08-15 04:38:47 -0500) edit

Woudl the unique together constraint work on ids for a many-to-one relationship? Meaning a thread can have only one location but one location can have many threads? Thanks for your help btw, it's much appreciated.

shano's avatar shano (2013-08-15 04:41:30 -0500) edit

If you add a constraint (id, thread) then each thread will have only one location. You could add a related table where there will be relation to thread and all the custom fields, potentially even with their own relation to other models. In that case the queries may become more complex and you might need to think later about caching the query results.

You could also just fork the code base and add extra fields with migrations added to another app not to askbot. This way merging in the future will be easier. Merging migrations may be difficult, so you can keep your migrations separately and declare dependencies explicitly - django-south has this functionality.

Evgeny's avatar Evgeny (2013-08-15 04:52:23 -0500) edit

I think you're right forking might be the least painful option considering the extensions I'll need to add. Thanks for your help.

shano's avatar shano (2013-08-15 05:12:06 -0500) edit

Possibly, the hardest part though may be to maintain migrations. You may have to experiment around that. Basically if you add migration to askbot and then we do also - you'll need to reconcile those manually. Simple git merge may not work.

Evgeny's avatar Evgeny (2013-08-15 05:22:02 -0500) edit

Maybe the best method will be to have an "extra app" with the migrations that add the extra field onto thread and have Thread.add_to_class() clause to actually add that field for the use in the django code - in the same manner as we patch the auth_user table. If you fork then it's best to not do any schema changing code in your fork as migrations may be indeed pain to maintain.

Evgeny's avatar Evgeny (2013-08-15 05:27:00 -0500) edit

Ah, so create a separate app that maintains any thread migrations and also use add_to_class in there to maintain the class fields, instead of altering the thread model.

shano's avatar shano (2013-08-15 05:35:31 -0500) edit
add a comment see more comments