Re: synchronize django admin interface password with other application passwords

[Phang Mulianto]

maybe you can just modify the create_user function in django , matching the
hash algorithm of the other backend, or the other backend matching to the
django backend.

you choose which one would be the single auth method.

and of course the admin interface is just as it, except you need custom
method. you need little effort still..

On Mon, Nov 7, 2011 at 10:13 AM, Gelonida N  wrote:

> Hi Mike,
>
> On 11/07/2011 12:15 AM, Mike Dewhirst wrote:
> > On 7/11/2011 7:43am, Gelonida N wrote:
> >>
> >> What would be the easiest way to hook into the password modification
> >> form, such, that I can calculate two password hashes with different
> >> salts / alorithms?
> >>
> > You need your own auth backend which inherits the existing django model
> > backend. Then borrow the offered password and create the other app's
> hash.
> >
> > https://docs.djangoproject.com/en/dev/ref/authbackends/
> >
>
> I'll look into it.
>
> At the moment I started creating my own 'create_user_form',
> which gets all info, and creates then the default user with
>
> django.contrib.auth.models.User.objects.create_user()
>
> and the other user with the other API
>
> But this is of course not that flexible as it does not allow
> to create users (or modify passwords) with the default admin interface.
>
>
> --
> 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.
>
>

-- 
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: bar charts

[kenneth gonsalves]

On Mon, 2011-11-07 at 00:04 -0500, Kevin Anthony wrote:
> Google charts api
> 
> 

any clues on how to integrate this with django?
-- 
regards
Kenneth Gonsalves

-- 
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: bar charts

[Kevin Anthony]

Google charts api

Kevin
Please excuse brevity, sent from phone
On Nov 6, 2011 11:57 PM, "kenneth gonsalves"  wrote:

> hi,
>
> what do people use to display bar charts in their sites?
> --
> regards
> Kenneth Gonsalves
>
> --
> regards
> Kenneth Gonsalves
>
> --
> 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.
>
>

-- 
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.

bar charts

[kenneth gonsalves]

hi,

what do people use to display bar charts in their sites?
-- 
regards
Kenneth Gonsalves

-- 
regards
Kenneth Gonsalves

-- 
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: synchronize django admin interface password with other application passwords

[Gelonida N]

Hi Mike,

On 11/07/2011 12:15 AM, Mike Dewhirst wrote:
> On 7/11/2011 7:43am, Gelonida N wrote:
>>
>> What would be the easiest way to hook into the password modification
>> form, such, that I can calculate two password hashes with different
>> salts / alorithms?
>>
> You need your own auth backend which inherits the existing django model
> backend. Then borrow the offered password and create the other app's hash.
> 
> https://docs.djangoproject.com/en/dev/ref/authbackends/
> 

I'll look into it.

At the moment I started creating my own 'create_user_form',
which gets all info, and creates then the default user with

django.contrib.auth.models.User.objects.create_user()

and the other user with the other API

But this is of course not that flexible as it does not allow
to create users (or modify passwords) with the default admin interface.


-- 
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: synchronize django admin interface password with other application passwords

[Mike Dewhirst]

On 7/11/2011 7:43am, Gelonida N wrote:

Hi,
I would like to use the django admin interface for authentification of a
web site.

However I also have to store a password hash (different algorith /
different salt) for another application, such, that both applications
can use the same password.

What would be the easiest way to hook into the password modification
form, such, that I can calculate two password hashes with different
salts / alorithms?




You need your own auth backend which inherits the existing django model 
backend. Then borrow the offered password and create the other app's hash.


https://docs.djangoproject.com/en/dev/ref/authbackends/

Mike

--
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: Relation not found error while dealing with foreign keys and forms

[Tabitha Samuel]

Hey thanks a bunch for the workaround. Maybe I am doing something
wrong, but this is what I'm getting when I implement it and it really
seems weird..

in my view I have:
staff_person =
Staff.objects.using('gold').get(username=current_staff)
form = StaffForm(instance = staff_person)
group
=NICSGroupType.objects.using('gold').get(n_group_number=staff_person.nics_group.n_group_number)
form.nics_group = group
print form.nics_group
print form

The first print gives me "3" which is correct. The print form on the
other hand gives me the same:
Exception Type: DatabaseError at /staff/staffinfo
Exception Value: relation "n_nics_groups" does not exist

If I comment out that print and render the template, I get pretty much
the same error:
Exception Type: TemplateSyntaxError at /staff/staffinfo
Exception Value: Caught DatabaseError while rendering: relation
"n_nics_groups" does not exist
and the problem line in the template is: NICS Group: {{form.nics_group}}

So the question is how can it print the group number when I do a print
form.group_number but exception out when I do a print form?

Tabitha

On Nov 5, 11:26 am, Furbee  wrote:
> As a workaround to this bug, you could get the group separately, and attach
> all of the group fields to the staff form manually until a fix is
> implemented. Something like (hasn't been tested, you may need to assign
> each NICSGroupType field to a form field):
>
> staff = Staff.objects.using('gold').get(username=current_staff)
> form = StaffForm(instance = staff)
> group =
> NICSGroupType.objects.using('gold').get(n_group_number=staff.nics_group.n_group_number)
>
> form.nics_group = group # this may attach all fields, but most likely
> you'll have to attach them manually, since they would just be a goup, not
> FormFields.
>
> Hopefully that will get you through this jam, until a fix is created. I
> haven't written any patches before, but I will see if I can figure it out,
> time permitting.
>
> Thanks,
>
> Furbee
>
>
>
>
>
>
>
> On Fri, Nov 4, 2011 at 3:36 PM, Furbee  wrote:
> > No worries. Wow, I've got some interesting results. I am pretty sure the
> > ModelForm class has a bug in it that it is not looking at the secondary
> > database with the using() method. It is a bug in the foreign reference
> > fields only, though.
>
> > I set up tables in my default database, and in an extra database named
> > staff, which is set up in settings.py.
>
> > In default DB:
> > n_test_staff
> > username;nics_group
> > "tsamuel";1
>
> > n_nics_groups
> > n_group_number;n_group_name
> > 1;"Group1"
> > 2;"Group2"
>
> > In staff DB:
> > n_test_staff
> > username;nics_group
> > "tsamuel";2 (Notice tsamuel in group 2 in this DB)
>
> > n_nics_groups
> > n_group_number;n_group_name
> > 1;"Staff1"
> > 2;"Staff2"
>
> > In the models, wrote __unicode__(self): method to show the groups.
>
> > Here's something strange:
> > >>> from models import Staff, NICSGroupType
> > >>> from django.forms import ModelForm
> > >>> class StaffForm(ModelForm):
> > ...     class Meta:
> > ...         model = Staff
> > ...
> > >>> staff = Staff.objects.using('staff').get(username='tsamuel')
> > >>> print staff
> > tsamuel 
> > >>> form = StaffForm(instance=staff)
> > >>> print form
> > Username: > id="id_username" type="text" name="username" value="tsamuel" maxlength="50"
> > />
> > Nics group: > name="nics_group" id="id_nics_group">
> > -
> > 2: Group2
> > 1: Group1
> > 
>
> > Notice this ModelForm is getting the Staff data from the 'staff' database,
> > but is getting the reference n_nics_groups data from the default database's
> > n_nics_groups table. Remember in staff tsamuel was part of group 2, which
> > is the selected option, but the label is Group2 instead of Staff2, which is
> > the value in n_nics_groups table in the 'staff' database.
>
> > Then I tried deleting the default database n_test_staff table to verify:
> > >>> from models import Staff, NICSGroupType
> > >>> from django.forms import *
> > >>> class StaffForm(ModelForm):
> > ...     class Meta:
> > ...         model = Staff
> > ...
> > >>> staff = Staff.objects.using('staff').get(username='tsamuel')
> > >>> form = StaffForm(instance=staff)
> > >>> print form
> > Username: > id="id_username" type="text" name="username" value="tsamuel" maxlength="50"
> > />
> > Nics group: > name="nics_group" id="id_nics_group">
> > -
> > 2: Group2
> > 1: Group1
> > 
>
> > Now, if I delete the default database's n_nics_groups table also, so it
> > should all be using the 'staff' database, the only place n_test_staff and
> > n_nics_groups exist now.
> > >>> from models import Staff, NICSGroupType
> > >>> from django.forms import *
> > >>> class StaffForm(ModelForm):
> > ...     class Meta:
> > ...         model = Staff
> > ...
> > >>> staff = Staff.objects.using('staff').get(username='tsamuel')
> > >>> print staff
> > tsamuel 
> > >>> form = StaffForm(instance=staff)
> > >>> print form
> > 

Re: Python data structures and the GIL

[Masklinn]

On 2011-11-06, at 22:07 , Tobia Conforto wrote:
> 
> I also guessed that deserializing a complex data structure at every AJAX 
> request would seriously impact performance.
Have you *tested* this assumption?

Because, to me and without any hard numbers, wanting to keep trees in-memory 
kind-of sounds like premature optimization. FWIW, on my machine reading a 60k 
XML document from memory (string or StringIO) takes cElementTree ~30ms and 
serializing it back takes roughly the same. While 60ms/request is not 
insignificant, I'm not sure it's worth the complexity you're trying to 
introduce.

-- 
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: Python data structures and the GIL

[Martin J. Laubach]

  One possibility that springs to mind is shared memory, either the sysv 
shmem variant or memory mapped files.

mjl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/enxR6iiOWHkJ.
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.

Python data structures and the GIL

[Tobia Conforto]

I have a Django app that does some heavy calculations for the user.

At the start of a user's session it parses some source data and builds
a complex data structure, in the form of big trees of cElementTree
nodes (by themselves fast and small, being written in C). Then it
allows the user to query and manipulate the data structure, using an
AJAX interface.

I can't store the cElementTree data structure in Django's session,
because it's made of unserializable C objects. I also guessed that de/
serializing a complex data structure at every AJAX request would
seriously impact performance. So it needs to stay in RAM, in the form
of Python and C objects.

The way I'm doing it now, there is a global variable in one of my
modules with a dict to map a user's session id with the data
structure. A cleanup algorithm purges stale entries after a given
timeout from the last access.

This forced me to deploy the project with method=threaded, to ensure
there is only one of those cache dicts.

I've given some thought to Python's GIL and the kind of bottleneck it
must be in a method=threaded deployment (in a high-load scenario, with
many users waiting for an answer and many CPU cores to be used,
otherwise it would make no difference).

The only reasonable alternative I see is to use pure Python
ElementTree objects (instead of the unserializable C ones) and store
them in Django's sessions over memcached. This would allow for a
method=prefork deployment. Whether the lack of inter-user Python
locking would offset the cost of using a somewhat larger and slower
data structure and un/pickling it at every request, remains to be
seen.

Any thoughts?

Tobia

-- 
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.

synchronize django admin interface password with other application passwords

[Gelonida N]

Hi,
I would like to use the django admin interface for authentification of a
web site.

However I also have to store a password hash (different algorith /
different salt) for another application, such, that both applications
can use the same password.

What would be the easiest way to hook into the password modification
form, such, that I can calculate two password hashes with different
salts / alorithms?


-- 
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 do I define a default (override-able) primary key field on an abstract model?

[g]

I have come up with a way to do this below.  Is there a better way?
Obviously the CharField is just for demonstration.  The real field
would need to create a usable id.  Here is what I have so far:

from django.db.models import Model, CharField
from django.db.models.base import ModelBase

class Base(ModelBase):
def _prepare(cls):
needs_primary_key = True
for field in cls._meta.fields:
if field.primary_key:
needs_primary_key = False
break
if needs_primary_key:
auto = CharField(verbose_name='ID', primary_key=True,
max_length=255)
cls.add_to_class('id', auto)
super(Base,cls)._prepare()

class CustomAutoID(Model):
__metaclass__ = Base
class Meta:
abstract = True



On Nov 5, 8:05 pm, g  wrote:
> I do not guess I was clear with my problem, so I am going to try to
> state it more clearly.
>
> I know that I am defining two primary keys and this is the problem.
> Using a OneToOneField as a primary key is fine.  However, I want to
> set up the base abstract model to *only* define the primary key (id =
> SomeAwesomeIDField(primary_key=True)) if the inheriting class does not
> define a primary key...  similar to the way that the default model
> does with an AutoField.  I do not want subclasses of my base class to
> use the auto increment primary key by default.
>
> I used different names for the primary keys because I was trying to
> show that I did not want to force the primary key to be named "id".
> Rather, I want to check for any primary key already present on the
> class.  Hence the use of "a" and a OneToOneField.
>
> For example, one solution to the problem would be to use two abstract
> base classes.  One that defines common fields, and one that defines
> the id.  And then only use both abstract classes for model A and only
> common fields for model B.
>
> However, I would prefer to only have one base class.  As such, I am
> looking to implement an automatic id field similar to how
> django.db.models.Model does it.  The problem is that after looking at
> the source code, I am not sure where this takes place.
>
> So, is it possible to conditionally define model fields in an abstract
> model base class depending on the fields defined in the subclass?
>
> If not, why?  Where and/or how does this automatic field get assigned
> when using models.Model?
>
> Thanks
>
> On Nov 5, 7:02 pm, Kurtis Mullins  wrote:
>
>
>
>
>
>
>
> > Good point, Furbee!
>
> > "g", I was going to suggest just overriding that "id" field -- but I read
> > the docs real quick and they say:
>
> > "It is an error to have fields in the abstract base class with the same
> > name as those in the child (and Django will raise an 
> > exception)."https://docs.djangoproject.com/en/dev/topics/db/models/#abstract-base...
>
> > So yeah, the initial error is definitely that you're trying to have
> > multiple primary keys for a single table (Model). In the end, you might
> > also have problems trying to use a relationship as a Primary key as well.
>
> > On Sat, Nov 5, 2011 at 6:53 PM, Furbee  wrote:
> > > I can't speak to the reference field being used as a primary key, but the
> > > initial error is that you have multiple primary keys on the single model 
> > > B.
> > > If it 'is-a' class Base, it inherits id as a primary key, and also defines
> > > a and a primary key. You cannot have multiple primary key fieds, hence
> > > "table B has more than one primary key."
>
> > > Furbeenator
>
> > > On Sat, Nov 5, 2011 at 3:48 PM, Kurtis Mullins 
> > > wrote:
>
> > >> I don't think the problem is overriding the Primary Key. I could be
> > >> wrong, but I think the actual problem here is that you can not use
> > >> OneToOneFields, ManyToManyFields, or ForeignKeys as primary keys. I'm not
> > >> sure how it would work on a database level. Like I said, I could be wrong
> > >> -- but that's my initial hunch. Try overriding it with something else 
> > >> like
> > >> an IntegerField and see if you still get an error.
>
> > >> On Sat, Nov 5, 2011 at 6:19 PM, g  wrote:
>
> > >>> How do I define a custom primary key field on Base that can be
> > >>> overridden by B without an error?
>
> > >>> class Base(Model):
> > >>>        class Meta:
> > >>>                abstract = True
> > >>>        id = SomeAwesomeIDField(primary_key=True)
> > >>>        other_common_field = AwesomeField()
>
> > >>> class A(Base):
> > >>>        pass
>
> > >>> class B(Base):
> > >>>        a = OneToOneField(A,primary_key=True)
>
> > >>> django.db.utils.DatabaseError: table "..." has more than one primary
> > >>> key
>
> > >>> --
> > >>> 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