#django

How do I access an objects fields when it's being created from a form

Can you file a ticket, please. The problem is the way Django tries to detect what changed. And since all arguments passed into a Field are taken into account, Django compares now() with now(), which is obviously not the save

bryantp: instance = form.save() ; instance.myfield

MarkusH: I'm quoting you, give me a minute to fill the ticket

TaiSHi: thanks

Can you past the Coin, model, too. Please

What about if the model that needs to be saved need information from another model?

In this case, the other model's id

bryantp: you can override the form's save() method

Ok.

Hopefully I am thinking about this correctly. I am trying to create two objects with one form.

Similar to how the admin page does it

bryantp: https://docs.djangoproject.com/en/1.6/topics/fo...

bryantp: that depends

MarkusH: Finishing it, I pasted coin model of course

bryantp: You can put the same form in a single view multiple times, using prefixes: https://docs.djangoproject.com/en/1.6/ref/forms...

thanks, TaiSHi

what's the ticket number?

I don't know if I submitted it correctly, sorry

Not a lot of experience on testing

TaiSHi: it's fine

Would that work with a modelformset_factory?

MarkusH: How could I modify my current model to avoid this ?

is django-activelink one of the better packages for active/highlight page functionality?

TaiSHi: drop the default from the field, and override the save method: def save(*args, **kwargs): if not self.last_sync: self.last_sync = now(); super(...)

that's what I'd do

TaiSHi: I've commented on your ticket: you don't want to use default=datetime.now(), as that gets evaluated at import time.

TaiSHi: If you use default=datetime.now, it will actually work as you want it to (and probably won't keep thinking the column needs to be changed).

Let me try

MarkusH: regarding your answer, I'm rather new to all of this, so your suggestion is basically no default and then define the default on save method ?

TaiSHi: Indeed, last_sync having a default is worthless, as you'll want to update the value whenever a sync occurs.

TaiSHi: give schinckel's idea a try

schinckel: It worked

is that not a place to use add_now?

AntelopeSalad: That's frowned upon in certain circumstances :)

AntelopeSalad: might be

But I probably would, although last sync implies something other than just last modified

schinckel: yes, it should be updated everytime a sync occurs but what would be the initial value?

schinckel: nice shot. wasn't aware that default takes a function and evaluates it

If no sync has occurred, then it should be None.

It depends what a 'sync' means.

sync / update, it will query a wallet for current balance

It may be that now is appropriate, but now() isn't, for the reason I outlined above.

now() is just the same as typing the date at the time the module is first imported: it's a static value for that run of the program.

Understood

It's not quite a bug but it works as intended

No, it is a bug.

If you start your system now, and it runs for three days, it will keep using the time you started the system as the defaults for that field for new instances.

hmm, so when you said passing it a callable, if you pass it the function without executing it, then it executes it on each instance creation?

schinckel: but then I'd use auto_now=True instead

which is more explicit in my eyes

schinckel: the question is: shall Django warn a user about that?

Well, haven't even started to code my app and already found a bug

i'm using auto_now with 1.6.1 with no warnings

using a "hard-coded" date/time/datetime object in the field.

This might be foretelling

Apparently there was a push to have auto_now and auto_now_add deprecated. I've never had problems with them, but having a default=datetime.datetime.now is probably more explicit and 'standard python' than auto_now_add.

As for auto_now, some people suggest overriding your save() method and putting it in there. Or there are a couple of mixins you can use to handle this.

IIRC, __love__'s django-braces has them, or was it django-model-utils?

auto_now* predates when default could take a callable, which is much cleaner.

Probably the latter, actually.

django-braces is CBV, django-model-utils is model/manager/field

Yeah, django-model-utils has created/modified fields, as well as the handy TimeStampedModel abstract model class.

schinckel it's django-extensions

unless both happen to have it

schinckel: isn't the difference, that auto_now* uses the database's NOW()?

Having generated a decent chat

TaiSHi: hehe, yes

from django_extensions.db.models import TimeStampedModel

If I were to want dates in YYYY-MM-DD

What would I need to do ?

AntelopeSalad: Same name in django-model-utils: https://django-model-utils.readthedocs.org/en/l...

I, pardon my words, hate north american date format

TaiSHi: just format them like that where you need them: {{ value|date:"Y-m-d" }}

schinckel: the only thing i don't like about extension's implementation is it forces an order by on the -modified date

TaiSHi: if you don't need time: DateField and adjust the DATE_FORMAT in the settings if it's global

Hmm

If I use DateTimeField would DATE_FORMAT be reflected ?

'Normals' tend to be a bit hostile towards ISO 8601 formatted dates though. I even use them in the real world, hilarity ensues.

ISO 8601 = YYYY-MM-DD (as seen in whiskey pedia)

Why would you call the other normals? ffuuu!!!

It's like inch system

God, I still can't get used to it

TaiSHi: For dates, yes. But also a standard for times, datetimes and intervals.

I mean normals for people who aren't computer programmers, basically.

you could use the short month name to avoid any confusion

ISO8601 also means you can just use string sorting on dates to sort them.

Indeed, but I quite don't care about the users regarding htat matter

that* even

sec, will prep a tea

TaiSHi: now, that your problem is solved, may I modify your ticket and propose a feature that adds a check stating the real problem you had?

MarkusH: feel free to do so

ok

As in, warning if you use datetime.now() as a default?

My issue is solved and I'm glad that it helped some purpose

served* or ... whatever

what's the cleanest way to detect if a form is create or update?

__love__ has been rather away these past couple of days

AntelopeSalad: A ModelForm?

create = form.instance.pk is None

schinckel: i want to output minor changes in my template