Re: Why are foreign keys rewritten when adding related_name?

[Hanne Moa]

No, 1.11. This project is still on Python 2.7 but I do think we'll
have it on Python 3(.5) before the year is over.

On Fri, 1 Mar 2019 at 21:16, Simon Charette  wrote:
>
> Hello HM,
>
> I know that some changes have been made to avoid unnecessary foreign key
> rebuilds on some option changes.
>
> Are you experiencing this on 2.1 and 2.2 pre release?
>
> Simon
>
> Le vendredi 1 mars 2019 02:40:01 UTC-5, HM a écrit :
>>
>> I added "related_name" to an exiting ForeignKey and checked with
>> "django-admin sqlmigrate" what would be done.
>>
>> It seems that the foreign key constraint is dropped, then the exact
>> same constraint is added back. Why?
>>
>> Example: If we have the classes:
>>
>> class Wall(models.Model):
>> ..
>>
>> class Door(models.Model):
>> ..wall = models.ForeignKey(Wall)
>>
>> and change Door.wall to models.ForeignKey(Wall, related_name='walls'), then:
>>
>> Prior to this, there exist (postgres) the constraint:
>>
>> "app_door_wall_id_45647_fk_app_wall" FOREIGN KEY (wall_id) REFERENCES
>> app_wall(id) DEFERRABLE INITIALLY DEFERRED.
>>
>> "django_admin sqlmigrate" reports:
>>
>> SET CONSTRAINTS "app_door_wall_id_45647_fk_app_wall" IMMEDIATE; ALTER
>> TABLE  "app_door" DROP CONSTRAINT
>> "app_door_wall_id_45647_fk_app_wall";
>> ALTER TABLE "app_door" ADD CONSTRAINT
>> "app_door_wall_id_45647_fk_app_wall" FOREIGN KEY ("wall_id")
>> REFERENCES "app_wall" ("id") DEFERRABLE INITIALLY DEFERRED;
>>
>> After running the migration, which is run as there's stuff in the log,
>> there exists seemingly the same constraint as before:
>>
>> "app_door_wall_id_45647_fk_app_wall" FOREIGN KEY (wall_id) REFERENCES
>> app_wall(id) DEFERRABLE INITIALLY DEFERRED.
>>
>> Why waste a connection this way?
>>
>> --
>> HM
>
> --
> 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 post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/a1d9f7a9-be2a-41d5-8a43-4b468ad4a547%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrrcnDAs%2BK59__zo0aMp0Xfk_aOz5okq-Hn6aacSYM8Mntg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Why are foreign keys rewritten when adding related_name?

[Hanne Moa]

I added "related_name" to an exiting ForeignKey and checked with
"django-admin sqlmigrate" what would be done.

It seems that the foreign key constraint is dropped, then the exact
same constraint is added back. Why?

Example: If we have the classes:

class Wall(models.Model):
..

class Door(models.Model):
..wall = models.ForeignKey(Wall)

and change Door.wall to models.ForeignKey(Wall, related_name='walls'), then:

Prior to this, there exist (postgres) the constraint:

"app_door_wall_id_45647_fk_app_wall" FOREIGN KEY (wall_id) REFERENCES
app_wall(id) DEFERRABLE INITIALLY DEFERRED.

"django_admin sqlmigrate" reports:

SET CONSTRAINTS "app_door_wall_id_45647_fk_app_wall" IMMEDIATE; ALTER
TABLE  "app_door" DROP CONSTRAINT
"app_door_wall_id_45647_fk_app_wall";
ALTER TABLE "app_door" ADD CONSTRAINT
"app_door_wall_id_45647_fk_app_wall" FOREIGN KEY ("wall_id")
REFERENCES "app_wall" ("id") DEFERRABLE INITIALLY DEFERRED;

After running the migration, which is run as there's stuff in the log,
there exists seemingly the same constraint as before:

"app_door_wall_id_45647_fk_app_wall" FOREIGN KEY (wall_id) REFERENCES
app_wall(id) DEFERRABLE INITIALLY DEFERRED.

Why waste a connection this way?

-- 
HM

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrrdbgWpcSgm85fDDskWNRXvYQ5hGyyo9yn5T5fyRj7%2BPQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading from Django 1.7: render_to_response and context_instance

[Hanne Moa]

This is only used in one app, and one views.py out of 38. There's only
this one views.py remaining that uses render_to_response with
context_instance. If this was modern Django code written by me I would
have used class-based views and a mixin modifying get_context_data
(Thank $deity for CBVs).

There is one other view that used something similar, through a
subclass of RequestContext instead of a local context processor. It
added two keys to every context in every view for that app/views.py.
There was never any overlap with what was put in the explicit context
so the fix was almost seddable.

This is a very lava flow heavy project so asking the original
developer about what the point was is out, and the point isn't
commented/documented either. (But who remembers 5 year old code at
that level of detail anyway?)

On 8 August 2018 at 15:42, Matthew Pava  wrote:
> If you are simply adding something to most every request, I would add a 
> context processor in the TEMPLATE settings.
>
> Check out 
> https://docs.djangoproject.com/en/2.1/topics/templates/#context-processors
>
> In this example, I have an app called general.  Within that is a py file 
> called context_processors.  In that file is a function called extra_context 
> that takes request as an argument.  I just return a dictionary that all of my 
> templates have access to.
>
> TEMPLATES = [
> {
> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
> 'DIRS': [
> # insert your TEMPLATE_DIRS here
> os.path.join(BASE_DIR, 'templates'),
> ],
> 'APP_DIRS': True,
> 'OPTIONS': {
> 'debug': True,
> 'context_processors': [
> # Insert your TEMPLATE_CONTEXT_PROCESSORS here or use this
> # list if you haven't customized them:
> 'django.contrib.auth.context_processors.auth',
> 'django.template.context_processors.debug',
> 'django.template.context_processors.i18n',
> 'django.template.context_processors.media',
> 'django.template.context_processors.static',
> 'django.template.context_processors.tz',
> 'django.contrib.messages.context_processors.messages',
> 'django.template.context_processors.request',
> 'general.context_processors.extra_context',
> ],
> },
> },
> ]
>
>
>
> -Original Message-
> From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On 
> Behalf Of Hanne Moa
> Sent: Wednesday, August 8, 2018 7:56 AM
> To: django-users@googlegroups.com
> Subject: Upgrading from Django 1.7: render_to_response and context_instance
>
> I'm upgrading a rather large code base from django 1.7, with the ultimate 
> goal to have it run on 1.11, as the code isn't fully verified to run on 
> python 3 yet.
>
> I'm replacing `render_to_response()` with `render()` everywhere a 
> RequestContext is used, and came upon this (simplified) oddity:
>
> return render_to_response(
>template,
>{'important': 1},
>context_instance=RequestContext(
>request, processors=[important_processor])
> )
>
> What important_processor() does is return a dictionary {''important":
> FOO} where the value of FOO depends on something in the request.
>
> Many other views' render_to_response() had this as its context_instance, but 
> they did not define 'important" in the dictionary before the 
> context_instance, so I replaced them with:
>
> return render(
>   request,
>   template,
>   important_processor(request) + {'whatever': 'was', 'in': 'here'}
> )
>
> In the first example I'm having some trouble figuring out which value for 
> "important" is visible to the template: is it 1, or whatever
> important_processor() generates?
>
> If I print what I think is context that is used to render the template, I get 
> a list of multiple dictionaries. The last two both have a "important"-key, 
> but with different values. {'important': 1} comes first of the two.
>
> I am neck deep in the template rendering code right now and I'm quite lost.
>
>
> HM
>
>
> (For statistics' sake , some 95% of the render_to_response()s looked like 
> this:
>
> return render_to_response(
>   some_template,
>   some_dict,
>   context_instance=RequestContext(request)
> )
>
> )
>
> --

Upgrading from Django 1.7: render_to_response and context_instance

[Hanne Moa]

I'm upgrading a rather large code base from django 1.7, with the
ultimate goal to have it run on 1.11, as the code isn't fully verified
to run on python 3 yet.

I'm replacing `render_to_response()` with `render()` everywhere a
RequestContext is used, and came upon this (simplified) oddity:

return render_to_response(
   template,
   {'important': 1},
   context_instance=RequestContext(
   request, processors=[important_processor])
)

What important_processor() does is return a dictionary {''important":
FOO} where the value of FOO depends on something in the request.

Many other views' render_to_response() had this as its
context_instance, but they did not define 'important" in the
dictionary before the context_instance, so I replaced them with:

return render(
  request,
  template,
  important_processor(request) + {'whatever': 'was', 'in': 'here'}
)

In the first example I'm having some trouble figuring out which value
for "important" is visible to the template: is it 1, or whatever
important_processor() generates?

If I print what I think is context that is used to render the
template, I get a list of multiple dictionaries. The last two both
have a "important"-key, but with different values. {'important': 1}
comes first of the two.

I am neck deep in the template rendering code right now and I'm quite lost.


HM


(For statistics' sake , some 95% of the render_to_response()s looked like this:

return render_to_response(
  some_template,
  some_dict,
  context_instance=RequestContext(request)
)

)

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrrfLhhHrtKVSvcwJ7SmNyePdybEhO50%2Bepd8hcuLEG5sgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Verify Emails

[Hanne Moa]

If you do your own email-sending code you can break off the sending after
the server sends "RCPT', that'll work regardless.

On 7 April 2018 at 14:27, 'Anthony Flury' via Django users <
django-users@googlegroups.com> wrote:

> why not use an email validator provided by Django ?
>
> https://docs.djangoproject.com/en/2.0/ref/validators/#emailvalidator
>
> The problem with the pypi module is that to validate that an email exists
> it simply looks for server in DNS (which is slightly better than the Django
> validator), but that doesn't mean that the :
>
>  * Email server will accept emails from you - or your service
>  * or that the user exists on that server ( even if the server exists).
>
> The only real way to validate that an email server is entirely valid is to
> send an email to it, asking for a reply. Email parsing will only go so far.
>
> In theory there is a defined protocol to allow clients to  query email
> servers for is valid email addresses - but most servers are set to ignore
> those requests - for obvious reasons.
>
>
> --
> Anthony Flury
> email : *anthony.fl...@btinternet.com*
> Twitter : *@TonyFlury *
>
> On 07/04/18 08:31, Samuel Muiruri wrote:
>
>> There's a python package for validating emails exists "validate_emails"
>> https://pypi.python.org/pypi/validate_email think it would be useful to
>> include it's features inside django so you can parse if emails exists
>> before sending so you only send emails to those emails that *do *exists and
>> also use it to get back those that don't so you can remove them from your
>> list like dummy emails provided to your subscription page.
>>
>> --
>> Best Regards,
>> Samuel Muiruri.
>> Student in Machine Learning & a veteran web developer.
>>
>> > =link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
>>  Virus-free. www.avast.com > il?utm_medium=email&utm_source=link&utm_campaign=sig-email&
>> utm_content=webmail&utm_term=link>
>>
>> --
>> 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 > django-users+unsubscr...@googlegroups.com>.
>> To post to this group, send email to django-users@googlegroups.com
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-users/CAJZFZXqyb9LQEmU_DHy1QToA6y1tmq3vwDBq28X%3D
>> LYDxZgdstw%40mail.gmail.com > sgid/django-users/CAJZFZXqyb9LQEmU_DHy1QToA6y1tmq3vwDBq28X%3
>> DLYDxZgdstw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-users/b2ad280e-fac2-f95f-d860-194a3046e6c8%40btinternet.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrrerKw57kNSHnG77CDg7L%2B1NzyiDCkv1yPWOHDkW%2B8bqTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: chemistry character set

[Hanne Moa]

On 2018-02-06 12:51, Mike Dewhirst wrote:
> Thank you. I think this is where we probably need to go. I asked the
> original question because I'm hoping the project will reach a tipping
> point and start to accumulate a growing number of multilingual users. We
> have our first multinational user but they only operate in the English
> speaking world so no pressure at the moment.

There can be no sort that satisfies every possible language at the same
time. For instance, Norwegian sorts "ä" as "a" and "ö" as "o". Swedish
sorts them after "å" as separate letters: åäö. Then there is Turkish
where "i" sorts differently from "ı" (dotless i).

I'm guessing chemistry names follow their own rules, you could see how
hard it is to make your own os collation table and use that? Then
everything running on the server would sort by the same rules.


HM

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d1bbe4f2-9036-d9d0-7217-38bba4d508aa%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

How to discover which postgres vesion is in use (on 1.11)?

[Hanne Moa]

When https://code.djangoproject.com/ticket/18332 lands (No generic way
to get database backend version) this will be trivial but I need a
solution for this now: How can I find out which version of postgres is
in use?

I need it thanks to JSONField. 9.6 has support for it but older
postgresqls don't, and I'd like to then use a third-party
json-in-TextField solution instead.

A model with a django.contrib.postgres.fields.JSONField cannot be
migrated on posgresqls older than 9.4. (We run 9.3 and I need this
project to run on >=9.3) You get 'django.db.utils.ProgrammingError:
type "jsonb" does not exist'. At that point it's a little late
swapping out the import.

-- 
HM

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrrekauCT-2HVHb7t-WtFxmp5Bq8mRTnThj%2Bb6AURP1b%3Dng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

How to add AutoField to/switch out primary key for an existing table?

[Hanne Moa]

A model was designed with a wrong assumption of uniqueness and given a
natural key. We now need to switch to a surrogate primary key.
Upgrading Django is currently not an option. The production database
may not be dropped/restored for this, it is in use by several
unrelated projects (remember the time before apis and microservices,
the time of really monolithic databases?)

This is for a project started before Django 1.0, currently running on
Django 1.7.

How do I migrate from here:

(assetname was thought unique on its own)

class MoveAssetToOrg(models.Model):
assetname = models.CharField(max_length=64, primary_key=True)
org = models.ForeignKey(Org)

class FreeSubscription(models.Model):
 ..
 moved_assets = models.ManyToManyField(MoveAssetToOrg)

class PaidSubscription(models.Model):
 ..
 moved_assets = models.ManyToManyField(MoveAssetToOrg)

to here?

(assetname is unique together with org)

class MoveAssetToOrg(models.Model):
id = models.AutoField(primary_key=True)
assetname = models.CharField(max_length=64)
org = models.ForeignKey(Org)

class Meta:
unique_together = ('assetname', 'org')

class FreeSubscription(models.Model):
 ..
 moved_assets = models.ManyToManyField(MoveAssetToOrg)

class PaidSubscription(models.Model):
 ..
 moved_assets = models.ManyToManyField(MoveAssetToOrg)

(Merging free and paid subscription is in the works but is not as time
sensitive.)

There are only a handful of entries in MoveAssetToOrg, and several
thousands in (Free|Paid)Subscription. Fortunately, there aren't any
other apps with knowledge of MoveAssetToOrg. It used to be the case
that assets were rarely moved, this is no longer the case.

I have considered using a fake composite key instead of a sequence,
with the key a string composite of assetname and org.id:

class MoveAssetToOrg(models.Model):
id = models.CharField(max_length=128, primary_key=True)
assetname = models.CharField(max_length=64)
org = models.ForeignKey(Org)

class Meta:
unique_together = ('assetname', 'org')

I have no good idea on how to do this with the migrations system either.


-- 
HM

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3Drrd-oM-RyBxsT-7f0U3HQXnde2SSQo7RMc%3DfwVzAnXKvYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Converting bytes to unicode that works both in python2 and 3

[Hanne Moa]

I got to start a new django 1.8-project in python 3.4 for once, and happily
coded away. Turns out, the PaaS it needs to run on has a broken python 3.4,
so... my code now needs to work in 2.7.8.

Everything works in both versions except I need to read from an uploaded
file, bot in the web and from the commandline. In the management command I
can do:

import io
with io.open(fieldname, 'rt', encoding='UTF-8') as F: do_stuff(F)

... and it works in both 2.7.8 and 3.4.x.

But a FileField in Python 3 reads stuff as bytes. So in the form, I need to
check whether the chunk of data I get is bytes, and if it is, convert it to
unicode from 'UTF-8'.

How to do that? It'll probably involve six in some way but the docs for
six, and django's "how to have things run on both python 2 and 3"-docs,
could be better.

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrrfKyM0O%3DamjOX2j9LTrvZQHS_3RJ8eo_Hyn9Js1ML9YBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Auth backends don't work with HttpResponseRedirect and Django 1.4+?

[Hanne Moa]

The fix that worked for 1.4.x did not work for 1.5.x.

Only thing that worked for 1.5.x was changing how apache called django, by
setting WSGIDaemonProcess to "processes=1" or removing "processes" entirely
("threads" can be lots more than one). Something has obviously changed in
how django does wsgi but I won't be spending more time trying to find out
why.

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrrcXYdKFJ50V4VJsR%3DbpO1pFUfX5xmOXs_zzd5j4DVC%3DgA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Auth backends don't work with HttpResponseRedirect and Django 1.4+?

[Hanne Moa]

Turns out: the auth backend that worked in 1.3 but not in 1.4+ was missing
a get_user()-method. I added it in and that was that.


HM

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3Drrc8yF%2BFq4BNm-ER0OTxVpDfDadrNtP8SMi30neVNswJNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Auth backends don't work with HttpResponseRedirect and Django 1.4+?

[Hanne Moa]

On 14 October 2013 17:06, Tom Evans  wrote:

> On Mon, Oct 14, 2013 at 1:52 PM, Hanne Moa  wrote:
> > I can't get logging in with alternate auth backends to work with Django
> 1.4
> > or newer.
>


> Are you sure sessions are working correctly? Are you setting cookies
> (for session or otherwise) with a different host name than you are
> serving from?
>
> Thx for the suggestion. With 1.3.1, a secure sessionid and and a csrf
token is set. With 1.5.4. the secure session id is also httponly, and the
csrftoken is also set. That's the only difference cookie-wise. I think I'll
dump the contents of the sessions to see what's going on.


HM

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrrfhybFuTJt4qgB-8OyxEnx2qZW%3DQVFzrW5Aqs8nrpxAWw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Auth backends don't work with HttpResponseRedirect and Django 1.4+?

[Hanne Moa]

That's not my code, that's the first hit on google for my problem. I use
django's own login() to login the user.


On 14 October 2013 15:07, Sergiy Khohlov  wrote:

>  Take a look  at :
> if form.is_valid():
> #django.contrib.auth.login
> Login(request, form.get_user())
> str = reverse('cm_base.views.index')
> return HttpResponseRedirect(str)
> else:
> # Their password / email combination must have been incorrect
> pass
>
> you  are verifying fields only. No more. And invalid creadentials (
> correct for form) are  never go to else  block
> Many thanks,
>
> Serge
>
>
> +380 636150445
> skype: skhohlov
>
>
> On Mon, Oct 14, 2013 at 4:01 PM, Sergiy Khohlov 
> wrote:
> > I have no idea why are you writing this code  by yourself ?
> >  This  is already done  !
> >  Take a look at
> >
> https://github.com/django/django/blob/master/django/contrib/auth/views.py
> >
> >  login function is already done  and you can  use it .  Have no sense
> > to write it by yourself.
> > Many thanks,
> >
> > Serge
> >
> >
> > +380 636150445
> > skype: skhohlov
> >
> >
> > On Mon, Oct 14, 2013 at 3:52 PM, Hanne Moa  wrote:
> >> I can't get logging in with alternate auth backends to work with Django
> 1.4
> >> or newer.
> >>
> >> Basically:
> >>
> >> 1. authenticate() works. request.user.is_authenticated() is True
> >> 2. Django's own login() seems to work, as request.user is set,
> >> request.session is set etc.
> >> 3. After the HttpResponseRedirect, request.user is AnonymousUser
> >>
> >> This has happened twice now, with different alternate auth backends. I
> can't
> >> get rid of Django 1.3 before this is fixed...
> >>
> >> In one project I can call the next view directly (with render) and it
> Just
> >> Works. In the current project, the next view contains a form, and the
> >> "login" doesn't survive the POST.
> >>
> >> What am I missing? See also the non-solution in
> >>
> http://stackoverflow.com/questions/16119155/django-request-user-not-set-after-redirect
> >>
> >>
> >> HM
> >>
> >> --
> >> 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 post to this group, send email to django-users@googlegroups.com.
> >> Visit this group at http://groups.google.com/group/django-users.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/d/msgid/django-users/CACQ%3DrreSearLz5zZyu1yZWnAx_CrSOW7u0f%3DnPdVHMMOX4DOhQ%40mail.gmail.com
> .
> >> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> 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 post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CADTRxJOnf8EkaR6tU5YMcKQ64GNOrHP7ShGKy2s4Wo6%3Dq1WU%3Dg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3Drre2CHhJdbX2gwObHOZkioZ-6H0vjCK-ujvBfYPjNewx3g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Auth backends don't work with HttpResponseRedirect and Django 1.4+?

[Hanne Moa]

Why not assume that I have a reason not to use the ready-made stuff?

The User-object has several passwords connected, wuhch represent passwords
elsewhere, which can be different. Which password to check is set on the
login-page, and after login the only page available is one where those
passwords can be changed.


On 14 October 2013 15:01, Sergiy Khohlov  wrote:

> I have no idea why are you writing this code  by yourself ?
>  This  is already done  !
>  Take a look at
> https://github.com/django/django/blob/master/django/contrib/auth/views.py
>
>  login function is already done  and you can  use it .  Have no sense
> to write it by yourself.
> Many thanks,
>
> Serge
>
>
> +380 636150445
> skype: skhohlov
>
>
> On Mon, Oct 14, 2013 at 3:52 PM, Hanne Moa  wrote:
> > I can't get logging in with alternate auth backends to work with Django
> 1.4
> > or newer.
> >
> > Basically:
> >
> > 1. authenticate() works. request.user.is_authenticated() is True
> > 2. Django's own login() seems to work, as request.user is set,
> > request.session is set etc.
> > 3. After the HttpResponseRedirect, request.user is AnonymousUser
> >
> > This has happened twice now, with different alternate auth backends. I
> can't
> > get rid of Django 1.3 before this is fixed...
> >
> > In one project I can call the next view directly (with render) and it
> Just
> > Works. In the current project, the next view contains a form, and the
> > "login" doesn't survive the POST.
> >
> > What am I missing? See also the non-solution in
> >
> http://stackoverflow.com/questions/16119155/django-request-user-not-set-after-redirect
> >
> >
> > HM
> >
> > --
> > 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 post to this group, send email to django-users@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-users.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/django-users/CACQ%3DrreSearLz5zZyu1yZWnAx_CrSOW7u0f%3DnPdVHMMOX4DOhQ%40mail.gmail.com
> .
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> 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 post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CADTRxJO%2BwGM0GtyECQiNEAQFJq-nqSQEn5vefPGU6oJx%3DJS8PA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrrdiG8nf9LJ1DrHLskBUerG2U3xHwyjDjLDSqJ7_TDRDyA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Auth backends don't work with HttpResponseRedirect and Django 1.4+?

[Hanne Moa]

I can't get logging in with alternate auth backends to work with Django 1.4
or newer.

Basically:

1. authenticate() works. request.user.is_authenticated() is True
2. Django's own login() seems to work, as request.user is set,
request.session is set etc.
3. After the HttpResponseRedirect, request.user is AnonymousUser

This has happened twice now, with different alternate auth backends. I
can't get rid of Django 1.3 before this is fixed...

In one project I can call the next view directly (with render) and it Just
Works. In the current project, the next view contains a form, and the
"login" doesn't survive the POST.

What am I missing? See also the non-solution in
http://stackoverflow.com/questions/16119155/django-request-user-not-set-after-redirect


HM

-- 
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACQ%3DrreSearLz5zZyu1yZWnAx_CrSOW7u0f%3DnPdVHMMOX4DOhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: After python upgrade, User.objects.get(username= doesn't work consistently

[Hanne Moa]

On 23 May 2012 00:30, akaariai  wrote:
> On May 22, 11:49 pm, Hanne Moa  wrote:
>> I upgraded python to 2.6.8 today from an earlier 2.6, what an
>> adventure! So much bizarre happenings so many places.
>
> Please provide these three things for further debugging:
>  - the exact Python code you try in the shell (including a real
> username).
>  - the SQL that generates (when not working).
>  - what does happen when you try to run that SQL in manage.py dbshell
> (you might need to add quotes to the parameters)

Problem solved. Exact lookups worked only intermittently in the
database as well. Turns out the index on usernames was hosed. I remade
it...

alter table auth_user drop constraint auth_user_username_key;
alter table auth_user add constraint auth_user_username_key UNIQUE (username);

and now it works. For a little while it was possible to make duplicate
users though (!) This calls for champagne, I've never seen an error in
the database that failed so spectacularly silently before =D


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: After python upgrade, User.objects.get(username= doesn't work consistently

[Hanne Moa]

On 22 May 2012 22:58, Kurtis Mullins  wrote:
> Sorry I'm a bit confused so I'm going to try to make some sense of
> your situation "out loud" :)
>
> 1. User.objects.get(username="some_username") works some-times

Yes.

> 2. When it doesn't work, then you get the DoesNotExist exception, right?

Yes.

> 3. If not, what error(s) do you see?

I haven't tried it on non-existing users. I except to get a user back.

> 4. Are you sure the user, with that username, does exist when you get
> the exception?

Yes. The user exists if I do an objects.all() or startswith/endswith.
I can do User.objects.get(id=... and get the user I want, i just can't
look em up by username.

> 5. If you are sure they exist and you still get the exception, did you
> look into the database itself to see if it exists? Or how did you come
> to this conclusion?

In a view I run User.objects.gte() by hand, then the user exists, then
a handful of lines later, still in the same view, User.objects.get()
for the same user is run by authenticate() (default ModelBackend) but
then the user does not exist. The database does not change in the
meantime.

The odd thing is it's only the auth.User model that shows this. Other
models are fine.


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

After python upgrade, User.objects.get(username= doesn't work consistently

[Hanne Moa]

I upgraded python to 2.6.8 today from an earlier 2.6, what an
adventure! So much bizarre happenings so many places. Tonight's
special:

SomeModel.objects.get(sometextfield=sometext) always works (when there
is one entry where sometextfield=sometext of course).

auth.User.objects.get(username=sometext) works only *sometimes*.

In a login-view, I first check that the user for a given username
exists. It does! User found. Then I try to authenticate:
auth.authenticate(user.username, password). That never works!
Monkeypatching authenticate() shows that the
User.objects.get(username=username) in it always returns
User.DoesNotExist. But of course:
User.objects.filter(username__startswith=username).get(username__endswith=username)
always return the user in question. And the only thing that has
changed is the minor python version.

I can't get User.objects.get(username=whatever) to work in the shell either.

How do I debug this further? This is for django 1.3, I need to have
this working predictably again before I can upgrade to 1.4. I have
logs of the sql if that'll help but the sql looks fine.


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Where are the women?

[Hanne Moa]

On 24 April 2012 16:14, Daniele Procida  wrote:
> I was looking at  again with excited 
> anticipation, and reading through the talk summaries.
>
>  - and 
> then I had a closer look at the names of this year's speakers.
>
> There are *two* women out of the 24 or so speakers listed, and only one is 
> doing a solo talk.

More generally, I would have liked to go to EuroPythonCon both this
year and last year but from experience I don't deal with hot and humid
weather very well so it's out of the question.

More specifically, when the base percentage of programmers vs.
non-programmers being different in the two sexes (this is also depends
on class and culture) is multiplied with the base percentage of
open-source programmers vs. non-open source programmers you will end
up with four different groups generally in four different sizes (Bayes
theorem!). We know that male programmers outnumber female programmers.
If non-open-source programmers outnumber open source programmers then
the group "female open-source programmer" is likely to be the smallest
group.

You can then set up a new test with "female programmers" vs. "male
programmers" and "programmers that visit techie cons" vs. "programmers
not visiting techie cons". The group "female open-source programmer
that visit techie cons" will have fewer members than "female
open-source programmers".

You get the idea. It might be that running those numbers will explain
the low number of "female open-source programmer that visit techie
cons that also are of interest to you" all by itself, no conspiracy
required.

You get more women in by changing the weights in *any* of the tests:
more programmers, more female programmers, more open source
programmers, more programmers visiting techie cons etc. It adds up.

So: you have this wee group of potential "female open-source
programmer that visit techie cons that also are of interest to you".
Then, and only then can you start to look at con-specific or
language-specific tests that the community can directly do something
with: "bro"grammers, strip shows, excessive drinking and pressure to
drink (rumored to be a problem at Java Script venues), rock star
behavior (ruby?), specific idiots that should never have been left out
of the asylum and ruins it for everyone etc.

I haven't heard any rumors of stupid behavior among pythoneers or at
python cons though so it might just be that "female open-source
(python and django) programmer that visit techie cons that also are of
interest to you" is a very small group.


HM, member of "open source programmers that don't get a paid trip to
visit techie cons that often and can't function very well in hot
climates"

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Where do ya'll put your glue models?

[Hanne Moa]

Say that there's an excellent 3rd party app "articles" with a model
Article and another most excellent 3rd party app "polls" with a model
Poll. How do you glue them together?

If an Article may have several Polls and a Poll may be used in several
Articles, you can glue them together with a new model with a foreign
key to each of Poll and Article. But where do you place these glue
models? Some possibilities are:

1. monkey patch or fork one or both of the 3rd party apps. Then you
have a problem when there's a new upstream version of the
patched/forked app.
2. make an app "articlepoll" to hold the ArticlePoll model. This app
can then be reused by other projects, but you might wind up with
zillions of them.
3. make an app "glue" for ArticlePoll and any other glue models you
need. This app is then 100% project-dependent.
4. treat the project as an app and add the glue models there.
...
last. a combination of the above.

What other possibilities are there? What is best practice?

I'm refactoring and upgrading a project that is very fond of option 1
at the mo' and there *must* be a better way.


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to add a ManyToManyField "dynamically" to a model?

[Hanne Moa]

On 20 December 2011 19:07, huseyin yilmaz  wrote:
> Generic forign key might help you

I want to avoid Generic Foreign Keys as I don't like them much,
philosophically speaking. I want something that is easier to work with
from the SQL side of things.


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

How to add a ManyToManyField "dynamically" to a model?

[Hanne Moa]

I have some apps app1, app2, .. appN and a special app for metadata.
The model metadata.Metadata should have ManyToManyFields to models (to
primary key, nothing fancy) in some of the other apps. I don't want to
have to update the models of the existing apps and the apps/models
shouldn't be hard-coded in the metadata-app in any way.

Now, one way I want very much to avoid is to make another app, let's
call it "glue", that hardcodes one model per wanted ManyToManyField
like so:

class GlueModel1Metadata(Model):
model1 = ManyToManyField(Model1)
metadata =  ManyToManyField(Metadata)

I've figured out how to "dynamically" create a Through-style model
(like the above) but I don't want them to be Through-style models.
(Dynamically is in quotes because I don't need to make tables at
runtime. Making them up front through syncdb is fine.)

Instead I'd rather register the models that need a manytomany to
Metadata and create all the connection tables in one fell swoop, via
syncdb, so I get that bit out of the way.

But... I'm stumped. The examples from AuditTrail at the wiki and the
revision history stuff in Pro Django is for full-blown models, not
ManyToMany tables. Besides, the models that are to use the audit
trail/history have that fact hardcoded in.


HM . o 0 ( monkey patch! )

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best practice for maintaining the "Django stack"

[Hanne Moa]

If you put something in INSTALLED_APPS, it *is* imported, and when you
test everything it is also tested.


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Managing different user types

[Hanne Moa]

On 10 February 2010 13:27, ALJ  wrote:
> 1. The best way to do a simple extension of user information?
> As far as I can tell, the best way is to use User Profiles. Ok. I get
> that.
> - "Storing Additional Information About Users" (http://
> docs.djangoproject.com/en/1.1/topics/auth/#storing-additional-
> information-about-users)

If you need more than one type of profile, you can use OneToOne from X
to User or the profile-model.

> 2. How about controlling how different user types show up in the admin
> interface?

One per OneToOne? You could automatically copy say username to the
OneToOne/profile, then User would be just for logging in/gluing stuff
together, and you would show the profile/onetoone in the admin.

> If you have someone administering the database, wouldn't it be better
> to have a clear distinction between the user types? So for example,
> instead of just users, would you have Teachers and Students split into
> different sections.

You could use different apps. That gives you different sections in the
admin for free.

> Or would you just have a single user interface,
> but with the ability to define the user type. Would you subclass in
> this instance?

> Perhaps create a custom Manager?

Generally a good idea anyway.

> 3. How do you extend beyond simple profiles?
> But what happens if not all users have the same profile types. For
> example, Students may have course info and education history,

ManyToMany between user/profile/onetoone and course/education.

> whereas Teachers won't need that.

Not true at a university, where the students become the teachers :)

> And how do you manage where information is
> required for one group, but not the other, such as teachers bank
> details or this years performance grade ... (ok not a great example
> but you get the idea).

OneToOne for all things specific to one group that is not repeated.

> 4. How do you manage the link between User Types and Authorisation
> Groups?
> Lets say for example I want teachers to have access to one type of
> interface and students access to another. Would you define a user type
> in the profile

Check if accessing the OneToOne of type X leads to DoesNotExist (in
code)/None (in template) or not. Existance of link == User is of type
X.

You could make auth-decorators/middleware that checks for the same
thing. I rarely bother with groups and permissions because of this.

I think you basically need to read up on data modeling, this link is
not too bad: http://www.agiledata.org/essays/dataModeling101.html


HM, disclaimer: did relational algebra (maths, not sql) at uni.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: django-tagging is not multi-db safe

[Hanne Moa]

2009/12/26 James Bennett :
> On Fri, Dec 25, 2009 at 1:06 PM, Hanne Moa  wrote:
>> How is one to use as_sql() now with multi-db in?
>
> One doesn't. And, generally, one should be sticking to the stable
> release of Django;

Kinda hard when one wants to experiment to see what needs to change in
order to upgrade to what will become the next stable version :) I'm
not running 1.2 on production code, no.

> third-party applications don't tend to offer guarantees of working with 
> unreleased development code.

Django-tagging have a lot of users though. Maybe the pinax-people will
arrange for a version that is 1.2-safe.


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: django-tagging is not multi-db safe

[Hanne Moa]

2009/12/26 Russell Keith-Magee :
> On Sat, Dec 26, 2009 at 3:06 AM, Hanne Moa  wrote:
>> A site using django-tagging will break hard on 1.2 as of today. See
>> issue http://code.google.com/p/django-tagging/issues/detail?id=233 .
>>
>> How is one to use as_sql() now with multi-db in?
>
> as_sql() is (and has always been) an internal function - it shouldn't
> be relied upon as public API for any application.

I've been using as_sql() for debugging myself. Running it without
arguments doesn't work, so how does one discover what arguments to
feed it?

> Looking at the ticket you linked, it appears that django-tagging has been 
> relying on
> the internals of sql.Query(), which isn't the best idea from the
> perspective of long term code maintainability.

Django-tagging have been relying on a lot of manual sql too, much that
must still remain manual. If only() would also affect what is listed
in a GROUP BY I think at least most of the manual sql could be
dispensed with. Heck, I want only() to work that way regardless. I
could dispense with the last manual sql in my own stuff, used to
calculate statistical mode over a column of integers.


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

django-tagging is not multi-db safe

[Hanne Moa]

A site using django-tagging will break hard on 1.2 as of today. See
issue http://code.google.com/p/django-tagging/issues/detail?id=233 .

How is one to use as_sql() now with multi-db in?


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: super() argument 1 must be type, not None

[Hanne Moa]

2009/12/22 TiNo :
> /../  for some reason it throws the
> following error since a while (don't know since when, don't know what
> changed, can't find anything suspicious in hg log...) "super() argument 1
> must be type, not None". When I run with pdb.set_trace as the first line of
> the save method in the dev server, I can see that Lid is indeed None. What
> is surprising is that ALL my imports are None (User, datetime, models,
> etc.). I vaguely remember encountering this error before, but I don't
> remember what I did to fix it.

I have no idea how to fix it but I might have seen a similar problem;
Have you inspected globals()? What happened to me was that the
imported names existed in globals but they all pointed to None, hence,
useless. I could reimport something in the scope it were to be used,
but a function couldn't see other functions/symbols in the same
module!


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Correct way to unlazify a SimpleLazyObject?

[Hanne Moa]

I recently got burned by r11626, which added SimpleLazyObject to
1.1.x. I have a templatetag that linkifies a user-object, and it
checks whether it is given a django.contrib.auth.models.User, an int
(looks up a User) or a profile (looks up the User). This check was
done with type(). Unfortunately, type(SimpleLazyObject) !=
type(User()), so I had a "fun" TemplateSyntaxError in my hands.

However, the TemplateSyntaxError never happened if there was an
instance of {{ user }} before the {% prettylinktouser user %} in the
template, thus it seems to me that just outputting a SimpleLazyObject
somehow unlazifies it. So, how can a SimpleLazyObject be unlazified
everywhere else?


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: What exactly does order_with_respect_to do?

[Hanne Moa]

2009/12/15 smcoll :
> i'd be curious to know if anyone has seen an admin implementation for
> reordering with this field.  i'd also heard some chatter a while back
> that this might be removed in future releases of Django, because it
> leans toward the "magic" end of things

I always end up making an explicit field "pos" for this anyway. Fewer surprises.


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Can't delete a User from within admin

[Hanne Moa]

2009/12/13 Ramiro Morales :
>> The manager's self is at that moment a
>> django.db.models.fields.related.RelatedManager.
>
> I'd suggest to read the Django documentation about managers,
> in particular the sections about default managers, and how they
> (are not) used by the admin application.

Then why has it worked just fine for months? I haven't changed
anything in the admin-setup or models.py for weeks, I've only been
improving the views lately.


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Can't delete a User from within admin

[Hanne Moa]

When I try to delete a user from within the admin I get:

TypeError at /admin/auth/user/

super(type, obj): obj must be an instance or subtype of type

It's triggered by:

File "/home/django-sites/CALS/cals/models.py" in get_query_set
  99. return super(DescriptionManager,
self).get_query_set().filter(current=True)

This manager sits on a model that has a foreign key to User.

class DescriptionManager(models.Manager):

def get_query_set(self):
return super(DescriptionManager,
self).get_query_set().filter(current=True)

class Description(Freetext):
# Freetext has abstract=True
..
objects = DescriptionManager()
..

The manager's self is at that moment a
django.db.models.fields.related.RelatedManager.

I can delete the User from within the shell just fine with
user_instance.delete()


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

WTF? global name 'TemplateSyntaxError' is not defined

[Hanne Moa]

Suddenly I get this:

Caught an exception while rendering: global name 'TemplateSyntaxError'
is not defined

The area in the template it is complaining about is in the
base-template, meaning the entire dev-version is broken. I haven't
changed anything in the templates lately, nor in the templatetag it is
complaining about. What I did was try out trunk, got a
csrf-error-message in the admin, switched back to 1.1, deleted all
.pyc-files in my project then reload the wsgi. So: WTF?


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to unregister model?

[Hanne Moa]

2009/11/25 Tomasz Zieliński :
> That patch is a hack that requires modifying live instance of Django,
> moreover I don't know what is influenced by it as I'm not that
> familiar
> with inner workings of model layer, so using it would be troublesome
> for me.
>
> So it seems that I have to write custom delete()s, using raw SQL..

There's a lot of tickets about the problems caused by implicit
cascaded deletes. Your use-case I think is new however (though, I've
been planning to use views myself...). You might want to collect all
of the "delete cascades" tickets and add your use-case to the most
relevant of them, mark all the rest as duplicates then tell the
developer-list.

Fixing this *is* on the roadmap for 1.2:
http://code.djangoproject.com/wiki/Version1.2Features
but: it has the lowest priority so there's room for you to step in.

Now for database views, what we really need is a way to mark that a
model is read-only/should never be updated in any way from/via django.


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Missing attribute on User

[Hanne Moa]

On Mon, Nov 23, 2009 at 00:46, Russell Keith-Magee
 wrote:
> On Mon, Nov 23, 2009 at 1:59 AM, Hanne Moa  wrote:
>> I have models M, N, which both have a foreignkey to User. When in the
>> shell/runserver, User has attributes for both M and N, but in a
>> batchfile ($ DJANGO_SETTINGS_MODULE=settings python batch.py) only M
>> is reachable from User while trying to get N leads to
>>
>> AttributeError: 'User' object has no attribute 'N_set'
>>
>> Wherever and how do I start debugging something like this?
>
> If model X has a foreign key pointing to model Y, model Y won't get
> the X_set attribute until model X is actually imported. This means
> that if X isn't imported, attributes will appear to be missing from Y.
>
> When you run under runserver, the INSTALLED_APPS setting is
> effectively an implied import of all the models listed.

So, settings isn't actually run properly (and thus the apps in
INSTALLED_APPS aren't all imported)  when doing

$ DJANGO_SETTINGS_MODULE=settings python script.py

?

So how is one supposed to do such things without going trough manage.py then?


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=.

Missing attribute on User

[Hanne Moa]

I have models M, N, which both have a foreignkey to User. When in the
shell/runserver, User has attributes for both M and N, but in a
batchfile ($ DJANGO_SETTINGS_MODULE=settings python batch.py) only M
is reachable from User while trying to get N leads to

AttributeError: 'User' object has no attribute 'N_set'

Wherever and how do I start debugging something like this?


HM

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=.

Re: Newbie Question: How to display only error messages when form validation fails?

[Hanne Moa]

On Fri, Sep 19, 2008 at 7:34 PM, Karthik Krishnan
<[EMAIL PROTECTED]> wrote:
> It throws a debug error page.

What Kenneth was trying to say was *which* error was in the debug error page.

> On Sep 18, 10:01 pm, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
>> On Friday 19 Sep 2008 7:02:06 am Karthik Krishnan wrote:
>>
>> > The premise is this: If the form validation fails, I want to display
>> > all the validation error messages on the top of the page in a special
>> > div tag that I have created.
>>
>> > {% for field, message in form.errors.items()%}
>> >   {{message}}
>>
>> > {% endfor %}

Unless you're using jinja you're misunderstanding what's possible in a
template. You can't have the () at the end of form.errors.items for
one and I'm not sure about automatic tuple-unpacking either (the
"field, message"-bit.) Django-templates ain't python.


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Deleting user cause integrity error ... violates foreign key

[Hanne Moa]

On Fri, Sep 19, 2008 at 1:51 PM, dbee <[EMAIL PROTECTED]> wrote:
>
> I'm trying to delete a user from my admin panel. The system tells me
> that it causes an integrity error by violating a foreign key
> constraint ...
>
> What causes these kinds of errors ?
>
> IntegrityError at /admin/auth/user/28/delete/
> ERROR: update or delete on "mot1_campaigns" violates foreign key
> constraint "$1" on "mobt1_response" DETAIL: Key (id)=(18) is still
> referenced from table "mot1_response". DELETE FROM "mot1_campaigns"
> WHERE "id" IN (18)

The row/object with id 18 in the "mot1_campaigns" is still stored in
the table "mot1_response" where the the field is not set as null. What
you could do is add an "ON DELETE CASCADE" on the foreign key in
"mot1_response", if you sql-server supports that. Then when you
delete, the row/object in "mot1_response" will be automatically
deleted also. You can't set this from inside Django though so it's
time to read the fine sql manual. If your server does not support ON
DELETE CASCADE you need to delete all dependent rows/objects manually
before you delete the user.


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Custom Comment Form - post_comment()

[Hanne Moa]

On Tue, Sep 2, 2008 at 12:29 PM, Thejaswi Puthraya
<[EMAIL PROTECTED]> wrote:
> For any general web-application, every user is expected to enter his
> details like first name and last name so it's not a usual case to have
> both of them empty.

I have several projects written in Django up and running right now,
none of them (even the half or so that uses django.contrib.auth) uses
the first_name and last_name for anything. If I need to have more than
a *username* I use a field display_name in the profile-model. This
elegantly gets around internationalization-problems: the japanese and
hungarians get to see their own names as they expect them to be seen
(family name first), to the limits of UTF-8, and even people like
Banksy or Madonna or Prince are allowed to use the service (not that
any of them ever would, mind). Most web services/sites, social or not,
ask far more than is necessary anyway, but then I am a recovering
cypherpunk... If the info isn't there, it can't be leaked.

For the record, I'm European, and there are European countries where
you need a license from the state and a certificate from the police to
be allowed to build a database of people, if the people in question
give the information freely or not. Furthermore, you must have a
system in place for the people in question to be allowed to correct
and/or remove their own info. Not needed with just a username =)


HM, in CYA-mode

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: per object permissions, caching and templates?

[Hanne Moa]

On Fri, Jul 25, 2008 at 11:39 AM, Bram de Jong <[EMAIL PROTECTED]> wrote:
> For freesound.org I really need per-object permissions and caching.
> I would also love to use the {% cache %} template tag as much as
> possible because it's so easy and transparent!
> Now, say for example I have a sound, and a user can either edit it or
> not, or vote for it or not.

AFAIK is_authenticated doesn't enter into it at all.

You meant per-object permissions as in
http://code.djangoproject.com/wiki/RowLevelPermissions yes? That link
has got examples also.

Model objects in Django are rows in a table in some SQL-capable
database. Some such databases already have a system for row-level
permissions but AFAIK every database does it differently... so Django
is getting a portable system, see link.

The question is really whether the system described in the link will
be 100% tied up with the admin-system or not. I haven't tried the
branch but have been using the newforms-admin branch (and need to
clean up my repos), if the rowlevelpermissions-branch is run as
competently as nfa was you have nothing to fear.


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: how to get form fields to show

[Hanne Moa]

On Thu, Jun 26, 2008 at 11:07 PM, Bobby Roberts <[EMAIL PROTECTED]> wrote:
> Ok i've got the form fields showing fine.  My form action is "." per
> the examples in the documentation.  The form is submitting and tracing
> through the view but i get a "view  didn't return an
> HttpResponse.object.
>
> here's my view:
>
> from forms import *

I'll assume that this is the forms.py of your app, not django? In that
case, it might be better to be explicit:

from myapp.forms import *  # Now also self-documenting!

> def DoPayDetailForm (request):
>if request.method =='POST':
>form = PayDetailForm (request.POST)
>
>if form.is_valid():
>AccountNum=request.POST.get('AccountNum','')

The point of .is_valid() (at least in newforms) is that you don't have
to do this. The data in request.POST is washed, cleaned, checked,
dried and put into form.cleaned_data, as a dict. No need to touch
request.POST.

>return render_to_response("step2.html",{'AccountNum':
> AccountNum, 'NameOnAcct': NameOnAcct,
>'Email': Email, 'Phone': Phone, 'NameOnCard': NameOnCard,
> 'Street1': Street1, 'Street2': Street2,
>'City': City, 'State': State, 'ZipCode': ZipCode, 'form':
> form}, context_instance=RequestContext(request))

I would do:

  data = forms.cleaned_data
  data['form'] = form
  return render_to_response('step2.html', data,
context_instance=RequestContext(request))

Actually, I would use a FormWizard, after patching it with the great
patch in ticket 6893 at http://code.djangoproject.com/ticket/6893 ,
and my own patch that makes it put the previous form in a session
instead of putting it in the next form.


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Form wizard problem

[Hanne Moa]

On Wed, Jun 4, 2008 at 6:31 PM, tyman26 <[EMAIL PROTECTED]> wrote:
> Unless I am really mistaken, I am pretty sure this is a bug.  The
> "self.step" variable in "wizard.py" is never being updated after the
> forms are submitted.  These are two possible fixes I found:

This is a known bug already, see tickets #7279, #7168, #6893. You
might want to add yourself to the cc-lists, or even help out. I use a
monkey-patched formwizard myself.


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: moving from MySQL to PostgreSQL on a "live" site ..

[Hanne Moa]

On Tue, May 20, 2008 at 10:32 AM, oliver <[EMAIL PROTECTED]> wrote:
> I take it doing via JSON you still need to convert the Boolean fields?
>
> would you know of any kind of scrip that would do it? as my editor
> doenst cope to well with 7mb of xml files :(.
> I guess its not to hard to write if needed.

If you're on linux, there's sed and awk, or you could go ridiculously
old school and build something out of cut, paste, tr, grep, sort, uniq
etc., or you could write a little python filter to do it all for you:

import sys

for line in sys.stdin:
# change the line somehow
print line

or you could write something in perl, or you could...

I have a filter that makes django's json-dumps more human-readable, by
adding a newline after every occurence of "}},". Running such a filter
first would make for short and snappy lines for the rewriting filter:

python manage.py dumpdata | prettifyjson | fixbooleans > postgres_safe.json


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Formwizard and dynamic initial data

[Hanne Moa]

Is Formwizard designed for new content only, or is it possible to use
it for changing existing content? I haven't been able to find an
obvious way to pass in run-time determined initial data anywhere, nor
how to pass in an instance (for ModelForms).

Have anyone found a way to pass in run-time initial or instance data?


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Authentication-backend problem

[Hanne Moa]

I have a type of user that is logged in to the site in a way
externally (SAML2-module for apache) to django (newest newforms-admin
branch). This external login-process leaves a token in the
environment-variables: while the token is in the envvars, the user is
logged in. (I hope to write a SAML2 module in pure python later this
year...) I have written an auth-backend to pick up and process this
token, that part works fine. The problem lies, however, in triggering
the authentication from the django side (and build a django-native
User-object if necesary.) I cannot test the auth-backend with
runserver since the token is built dynamically each time by apache, so
I'm using mod_wsgi (mod_python was just too frustrating!).

Now, my test-view calls authenticate() and then login() but I always
wind up with a 500 error. Even with loglevel set to debug, the
error-message/traceback in the apache error.log isn't very helpful.
Reproduced below, with the SSL-noise and most of the apache-noise
removed (the stuff after "referer:" cut to make the lines shorter,
line 2 is uncut):

[info] Subsequent (No.2) HTTPS request received for child 9 (server
anonymized.com:443)
[info] mod_wsgi (pid=21355, process='',
application='anonymized.com|'): Loading WSGI script
'/home/python/django.wsgi'., referer:
https://idp.samlexample.com/amserver/SSORedirect/metaAlias/idp?ReqID=_D1B2D3FF6936D432B62D916AB48DDB33
[error]  mod_wsgi (pid=21355): Exception occurred processing WSGI
script '/home/python/django.wsgi'., referer:
[error]  Traceback (most recent call last):, referer:
[error]File
"/usr/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line
209, in __call__, referer:
[error]  response = middleware_method(request, response), referer:
[error]File
"/usr/lib/python2.5/site-packages/django/contrib/sessions/middleware.py",
line 37, in process_response, referer:
[error]  request.session.save(), referer:
[error]File
"/usr/lib/python2.5/site-packages/django/contrib/sessions/backends/db.py",
line 42, in save, referer:
[error]  session_key = self.session_key,, referer:
[error]File
"/usr/lib/python2.5/site-packages/django/contrib/sessions/backends/base.py",
line 109, in _get_session_key, referer:
[error]  self._session_key = self._get_new_session_key(), referer:
[error]File
"/usr/lib/python2.5/site-packages/django/contrib/sessions/backends/base.py",
line 101, in _get_new_session_key, referer:
[error]  if not self.exists(session_key):, referer:
[error]File
"/usr/lib/python2.5/site-packages/django/contrib/sessions/backends/db.py",
line 35, in exists, referer:
[error]  Session.objects.get(session_key=session_key), referer:
[error]File
"/usr/lib/python2.5/site-packages/django/db/models/manager.py", line
69, in get, referer:
[error]  return self.get_query_set().get(*args, **kwargs), referer:
[error]File
"/usr/lib/python2.5/site-packages/django/db/models/query.py", line
261, in get, referer:
[error]  obj_list = list(clone), referer:
[error]File
"/usr/lib/python2.5/site-packages/django/db/models/query.py", line
114, in __iter__, referer:
[error]  return iter(self._get_data()), referer:
[error]File
"/usr/lib/python2.5/site-packages/django/db/models/query.py", line
486, in _get_data, referer:
[error]  self._result_cache = list(self.iterator()), referer:
[error]File
"/usr/lib/python2.5/site-packages/django/db/models/query.py", line
189, in iterator, referer:
[error]  cursor.execute("SELECT " + (self._distinct and "DISTINCT
" or "") + ",".join(select) + sql, params), referer:
[error]File
"/usr/lib/python2.5/site-packages/django/db/backends/util.py", line
18, in execute, referer:
[error]  return self.cursor.execute(sql, params), referer:
[error]  ProgrammingError: current transaction is aborted, commands
ignored until end of transaction block, referer:
[error]  , referer:
[info]  Connection closed to child 9 with standard shutdown (server
anonymized.com:443)

(Yep. the second to last line was just a comma + referer).

Anyone seen this before? Where do I even start to look?

I'll also be needing to read an auth-token from a cookie later on,
again never going via a django-controlled login-page.


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Problems with ManyToManyField

[Hanne Moa]

This model: http://dpaste.com/35309/
...
Being accessed through this authentication-backend while logging into
the admin-interface: http://dpaste.com/35312/
...
Leads to this traceback:  http://dpaste.com/35310/

Removing lines 18 to 22 in the middle paste fixes things.

Now, all the renaming is due to using an existing database.

The Bruker and Gruppe models don't have an admin-interface nor any
views or templates and they won't be needing any, ever. I do it like
this to access them because it seems quicker than writing my own sql
access-code...

So, what's up? There's no link between the code and the traceback that
I can see.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Where's HttpRequest?

[Hanne Moa]

I'm writing an authentication-backend and need to check if a cookie
already exists. But: how do I get ahold of the HttpRequest?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Is this a OneToOne or something else?

[Hanne Moa]

On Feb 12, 2008 2:58 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-12 at 14:51 +0100, Hanne Moa wrote:
> > On Feb 12, 2008 2:23 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > > On Tue, 2008-02-12 at 14:13 +0100, Hanne Moa wrote:
> > > > 1. how do I get "Region: 'someregion (somelocation)'" in the admin
> > > > interface instead of "Region: '-'"?
> > >
> > > [..] So there's something slightly amiss with
> > > the way things are matched up in your retrofitted models. You could also
> > > try comparing the output of "manage.py sql " to the actual
> > > database tables to make sure the reference is pointing to the right
> > > field, etc.
> >
> > I checked the generated sql. No wonder it went wrong. With db_column
> > in the ForeignKey, the attribute Org.region in python became org.id in
> > the sql, meaning there were several fields "id" in the same table!
> > When I removed db_column in ForeignKey, the Python attribute
> > Org.region became org.region_id in the table and hence not matching
> > the existing table.
>
> Use db_column="region".

Ah! We have liftoff! I thought db_column referenced the foreign table.
Well, I keep mixing up the order of arguments in split() and join()
to...


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Is this a OneToOne or something else?

[Hanne Moa]

On Feb 12, 2008 2:23 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-12 at 14:13 +0100, Hanne Moa wrote:
> > 1. how do I get "Region: 'someregion (somelocation)'" in the admin
> > interface instead of "Region: '-'"?
>
> I don't know why this is happening. ForeignKeys normally just work
> properly. It should be working as you expect.
>
> [..] So there's something slightly amiss with
> the way things are matched up in your retrofitted models. You could also
> try comparing the output of "manage.py sql " to the actual
> database tables to make sure the reference is pointing to the right
> field, etc.

I checked the generated sql. No wonder it went wrong. With db_column
in the ForeignKey, the attribute Org.region in python became org.id in
the sql, meaning there were several fields "id" in the same table!
When I removed db_column in ForeignKey, the Python attribute
Org.region became org.region_id in the table and hence not matching
the existing table. Too much automagic or what?

In case you wondered: inspectdb croaks on this monster so the models
are all hand-made.

So, new question: how do I prevent the python-attribute in the
Org-class from being renamed in the sql? Now, if I had made the
underlying sql I would never have called every primary key the same
though, because if you don't, you get to use natural joins, which
rocks when it comes to readability/maintenance of sql... but that's
just me.


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Is this a OneToOne or something else?

[Hanne Moa]

On Feb 12, 2008 1:56 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-12 at 13:36 +0100, Hanne Moa wrote:
> > class Region(models.Model):
> > id = models.IntegerField(unique=True, primary_key=True)
> > region = models.CharField(maxlength=32)
> > location = models.CharField(maxlength=32)
> > class Meta: db_table = 'region'
> >
> > def __str__(self):
> > return '%s (%s)' % (self.region, self.lokasjon)
>
> Here's the problem: your __str__ method will be throwing an exception
> because the lokasion attribute doesn't exist.

I knew you'd say that as soon as I sent it in when I noticed I hadn't
Anglified the "lokasjon"-attribute everywhere (why'd I do such a thing
in the first place? To make it easier for you, of course.)

Now, that typo isn't there in the actual running code. I don't get any
exceptions or errors when running it. I'll repeat my question:

1. how do I get "Region: 'someregion (somelocation)'" in the admin
interface instead of "Region: '-'"?
2. ...while at the same time ensuring that another Region can never be
added to that particular Org? Changed, yes, added, no.

By subclassing ForeignKey or is there a parameter/flag/option to set somewhere?

> > class Org(models.Model):
> > id = models.IntegerField(unique=True, primary_key=True)
> > ..
> > region = models.ForeignKey(Region, db_column = 'id') #x, Region.id
>
> By default, ForeignKeys refer to the primary key of the related model.
> So you can do away with the db_column attribute here if you want to be
> more succient.

Good to know.

> > http://www.djangoproject.com/documentation/faq/
> >
> > This FAQ doesn't contain answers to my type of question.
>
> a lot of questions of already been asked previously
> on this very mailing list. So I am suggesting that you do the natural
> things and search the mailing list archives (or just use Google and
> don't even restrict it to the django-user archives). View the mailing
> list as an ever-growing, live list of frequently asked questions (and
> multiple answers).

I'll take this as a suggestion to make a FAQ for these types of
questions as I detest having to only depend on search through a
mailinglist/wiki/bbs/irclog/whatever, then finding an answer from last
century with a solution that no longer works. Or a solution written in
a language I don't read. Or a solution to  the wrong problem, or...

I'll even strive to make this FAQ a proper Django app, now there's a
win-win for us all.


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: How popular is Django ?

[Hanne Moa]

On Feb 12, 2008 12:00 PM, tom <[EMAIL PROTECTED]> wrote:
> How popular is Django among other Python Web Frameworks (TurboGears,
> Pylons, Webware, CherryPy...) ?
>
> I found a link on the subject :
>
> http://www.therightsoft.com/softwaretechnologies/webframeworks

Where's Drupal on this list?


HM, who'd rather avoid php...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Is this a OneToOne or something else?

[Hanne Moa]

On Feb 12, 2008 12:51 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-12 at 12:44 +0100, Hanne Moa wrote:
> > On Feb 12, 2008 12:16 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > > On Tue, 2008-02-12 at 12:11 +0100, Hanne Moa wrote:
> > > > Each org only has a single region, and in the old web-interface the
> > > > region-data is shown as a drop-down-list () where you can
> > > > choose one and only one. So: org.region == region.id, there can be
> > > > many orgs in a region but only one region per org.
> > >
> > > Which means it's many-to-one, not one-to-one. If you were to draw a
> > > picture of your table rows, many rows would (potentially) be pointing to
> > > a single row in the org table. That's many-to-one.
> > >
> > > In Django a many-to-one relation is represented by a ForeignKey field.
> >
> > I'm using a ForeignKey-field for it now, but I don't see anywhere how
> > to make it behave as in the old system: in Django's admin-interface
> > for org the foreignkey is shown as a drop-down *but with nothing
> > selected*.
> >
> > When looking at the examples in the tutorial: Poll/Choice, a Poll can
> > have several Choices, but a Choice can have only a single Poll. But
> > org->region is *the other way around*. One Poll containing many
> > Choices vs. one org having one region. The fact that one region have
> > many orgs is irrelevant as region will never be editable or visible
> > anywhere else but as linked from org.
> >
> > So, how do I do that?
>
> Put the ForeignKey on the "many" side of the relation. In your case, it
> looks like it goes on the "org" model, since there are many orgs to a
> region.

I already have:

class Region(models.Model):
id = models.IntegerField(unique=True, primary_key=True)
region = models.CharField(maxlength=32)
location = models.CharField(maxlength=32)
class Meta: db_table = 'region'

def __str__(self):
return '%s (%s)' % (self.region, self.lokasjon)

class Org(models.Model):
id = models.IntegerField(unique=True, primary_key=True)
..
region = models.ForeignKey(Region, db_column = 'id') #x, Region.id
..
class Admin: pass

... and in the admin-interface for Org I see Region: '--'
instead of the expected Region: 'someregion (somelocation)'. If I add
'class Admin: pass' to Region I get to add more Regions to the Org,
which I never want. If I do the other examples in the tutorial I also
get to add more regions, which I never want.

I might have been unclear so I'll try again:
1. how do I get "Region: 'someregion (somelocation)'" in the admin
interface instead of "Region: '-'"?
2. ...while at the same time ensuring that another Region can never be
added to that particular Org? Changed, yes, added, no.

> > > There are very few 'new' questions of this nature.
> >
> > Then where's the FAQ?
>
> http://www.google.com/search?q=django+FAQ

http://www.djangoproject.com/documentation/faq/

This FAQ, which I read before I came here, and which I assume is
pretty official, doesn't contain answers to my type of question. So,
is there another FAQ for such? The obvious google didn't find any.


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Is this a OneToOne or something else?

[Hanne Moa]

On Feb 12, 2008 12:16 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-12 at 12:11 +0100, Hanne Moa wrote:
> > Each org only has a single region, and in the old web-interface the
> > region-data is shown as a drop-down-list () where you can
> > choose one and only one. So: org.region == region.id, there can be
> > many orgs in a region but only one region per org.
>
> Which means it's many-to-one, not one-to-one. If you were to draw a
> picture of your table rows, many rows would (potentially) be pointing to
> a single row in the org table. That's many-to-one.
>
> In Django a many-to-one relation is represented by a ForeignKey field.

I'm using a ForeignKey-field for it now, but I don't see anywhere how
to make it behave as in the old system: in Django's admin-interface
for org the foreignkey is shown as a drop-down *but with nothing
selected*.

When looking at the examples in the tutorial: Poll/Choice, a Poll can
have several Choices, but a Choice can have only a single Poll. But
org->region is *the other way around*. One Poll containing many
Choices vs. one org having one region. The fact that one region have
many orgs is irrelevant as region will never be editable or visible
anywhere else but as linked from org.

So, how do I do that?

> If you're just starting out, you're going to want to spend a bit of time
> searching in the django-users archives (or just searching in Google and
> making sure "django" is in the query). There are very few 'new'
> questions of this nature.

Then where's the FAQ?


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Is this a OneToOne or something else?

[Hanne Moa]

Just starting out with Django here...

In an existing database whose existing table-structure must remain
unchanged by django, I have several cases of what looks like a
OneToOne, for instance:

The table/class org has a field region which points to the id on the
table/class region (dump from postgres):

CREATE TABLE org (
  ..
  region integer,
  ..
);

CREATE TABLE region (
  id integer NOT NULL,
  region character varying(32) NOT NULL,-- county, state
  location character varying(32) NOT NULL  -- location within region
);

ALTER TABLE ONLY org
  ADD CONSTRAINT "$5" FOREIGN KEY (region) REFERENCES region(id);

Each org only has a single region, and in the old web-interface the
region-data is shown as a drop-down-list () where you can
choose one and only one. So: org.region == region.id, there can be
many orgs in a region but only one region per org.

Basically, tables like "region" act as helpers for the "real" tables
like "org", by limiting what region can be filled out for the org. The
"region"-table is basically readonly, as the only way to change
anything in it is to do so manually, with the right privileges,
directly with sql-commands.

This looks like a OneToOne to me, but OneToOnes are not to be used, so
what to do instead?

(Oh, and having a way to make a model inherit from another (single
inheritance is fine) would be swell. The obvious way didn't work.)


HM

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---