geodjango application in rhel 6

[Anju SB]

Friends,

 I have developed a geodjango application using python 2.7, django 1.4, 
mapnik, tilecache and postgis enabled postgresql in ubuntu 12.04. After 
completing the development I installed the same application in RHEL 6, but 
postgis query using geodjango API is not working. The query is

the_geom is geometry value from another table

placeDet = MyModel.objects.filter(thegeom__dwithin=(the_geom, 
250)).distance(the_geom).order_by('distance')

and in the Excepton it shows the error as,

'NoneType' object has no attribute 'group'


Please help me to solve this issue!
 

-- 
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/6a5fc3f1-215b-427b-8a51-95752f84aec7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

AttributeError | 'Template' object has no attribute 'render'

[Nakaya Mitsuo]

I got AttributeError.
Exception Value: 'Template' object has no attribute 'render'

How can I fix it?
Please help me.

--- CODE --

from django.shortcuts import render
from django.template import Context, Template

class US_AccountManager(models.Manager):
   def update_account(self, auth_user, email):
   us_profile = auth_user.us_profile
   if auth_user.email == email:
   pass
   else:
   try:
   mail_template = Mail_Template.objects.get(position = 'MC')
   context = Context({'site_root':site_root,
   'app_name':app_name})
   message = Template(mail_template.message).render(context)
   subject = mail_template.subject
   send_mail(subject, message, settings.DEFAULT_FROM_EMAIL, 
[auth_user.email])
   except Mail_Template.DoesNotExist:
   try:
   send_mail_dict = {'site_root':site_root,
   'app_name':app_name}
   subject = 'From' + app_name
   message = 
render_to_string('txt/change_email.txt',send_mail_dict)
   send_mail(subject, message, settings.DEFAULT_FROM_EMAIL, 
[auth_user.email])
   except:
   pass
   return auth_user


I want to send mail from template ( contain in database ).
And render the template.

Sorry my poor English.

-- 
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/75041768-887a-4b21-8514-472511a9c075%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A migration in one app that adds a field to another

[Justin Myles Holmes]

Carl:

Actually, the "subclass the operation" method fails for obvious reasons
here:

https://github.com/django/django/blob/df0523debcc2d0984f1bc11d323f04227d4b388b/django/apps/registry.py#L202

I'm increasingly thinking that using MIGRATION_MODULES and just
maintaining a local copy of Mezzanine's migration is the simplest
solution.  I sense that I'm going to face some resistance if I suggest
changing their docs to reflect this.  I'll start with a blog post.


On 11/04/2014 04:30 PM, Justin Myles Holmes wrote:
> Well, as I say, I don't particularly like this field injection notion,
> and I'm happy to individually subclass where needed in my own projects.
>
> I'm less surefooted about issuing a pull request to mezzanine to alter
> their docs to suggest doing this, although the doc is currently
> ambiguous enough to be of little use anyway.
>
> I think that you and Carl have changed my mind about the
> reasonableness of including migrations in one app for a model in
> another.  I'm no longer able to think of a scenario that justifies it.
>
>
> On 11/04/2014 04:12 PM, Andrew Godwin wrote:
>> Carl is right that this isn't a supported thing; Django models are
>> designed to be static, and not mutate based on settings.
>>
>> Migrations are designed to only support one linear change history of
>> models; swappable models are just about supported but not perfect and
>> leads to issues. Adding in the ability to change or remove other
>> fields based on installed models is kind of against the way
>> migrations is designed and you'll have to do a lot of work to get
>> around it.
>>
>> In this particular case, it's possible to make it work, but you'll
>> have to subclass every one of the actions you want to use and provide
>> a way to override the app_label it operates on, and manually
>> construct the migrations to get the dependencies correct and
>> non-circular (as I said, you'll have to do a lot of work to get
>> around it). As long as you have anything resembling magically
>> changing models in your project, you're not going to be able to use
>> anything makemigrations outputs and expect it to Just Work™.
>>
>> Andrew
>>
>> On Tuesday, November 4, 2014 3:59:23 PM UTC-8, Carl Meyer wrote:
>>
>> Hi Justin,
>>
>> On 11/04/2014 04:42 PM, Justin Myles Holmes wrote:
>> >> I don't understand this use case. A ForeignKey impacts only
>> one database
>> > table's schema; the table for the model on which the ForeignKey
>> field is
>> > located. The schema of the model the ForeignKey points to
>> doesn't need
>> > to change at all based on the presence or absence of some other
>> > ForeignKey pointing to it.
>> >
>> > Example:
>> >
>> > Two apps: apps.coconuts and apps.swallows, each with a
>> canonical model
>> > (Coconut and Swallow, respectively).
>> >
>> > The organization runs two version of the project: one with
>> apps.swallows
>> > and one without.
>> >
>> > The one with apps.swallows needs a field on Coconut, "carried,"
>> which is
>> > a FK -=> Swallow.
>>
>> This is basically the same use case as the Mezzanine one - it's
>> attempting to make a model more "reusable" by monkeypatching it with
>> additional fields from outside. I think this should be avoided and
>> discouraged, not better supported.
>>
>> The specifics of how to avoid would depend on details of the
>> case, but I
>> would look towards providing the reusable portions of the model
>> as an
>> abstract base, and maybe additionally using swappable models if
>> other
>> models need to have an FK to the "extendable" model.
>>
>> (Swappable models aren't yet formally supported for use outside
>> contrib.auth, and there are still rough edges in migration's
>> support for
>> them, but I think moving them towards formal support is a much
>> better
>> answer to this general use case than monkeypatching fields onto
>> models.)
>>
>> Another possibility (which I still don't like, but is better than
>> monkeypatching) might be to conditionally define the Coconut.carried
>> field, depending on the value of a setting. In that case, the right
>> solution for migrations is to still define the migration that
>> adds the
>> Coconut.carried field in the coconuts app, but make it
>> conditionally a
>> no-op migration based on the value of the same setting.
>>
>> > To me, the proper way to do this is to ship a migration in the
>> swallows
>> > app which adds this field to apps.coconuts.models.Coconut.
>>
>> Sorry, I don't agree that there's anything "proper" about that
>> :-) The
>> migration is a secondary issue here - the basic problem is that
>> you're
>> monkeypatching the Coconut model, and I don't think migrations
>> should
>> support/encourage one app monkeypatching another app's models.
>>
>> > This is certainly a rare use c

Re: A migration in one app that adds a field to another

[Justin Myles Holmes]

Well, as I say, I don't particularly like this field injection notion,
and I'm happy to individually subclass where needed in my own projects.

I'm less surefooted about issuing a pull request to mezzanine to alter
their docs to suggest doing this, although the doc is currently
ambiguous enough to be of little use anyway.

I think that you and Carl have changed my mind about the reasonableness
of including migrations in one app for a model in another.  I'm no
longer able to think of a scenario that justifies it.


On 11/04/2014 04:12 PM, Andrew Godwin wrote:
> Carl is right that this isn't a supported thing; Django models are
> designed to be static, and not mutate based on settings.
>
> Migrations are designed to only support one linear change history of
> models; swappable models are just about supported but not perfect and
> leads to issues. Adding in the ability to change or remove other
> fields based on installed models is kind of against the way migrations
> is designed and you'll have to do a lot of work to get around it.
>
> In this particular case, it's possible to make it work, but you'll
> have to subclass every one of the actions you want to use and provide
> a way to override the app_label it operates on, and manually construct
> the migrations to get the dependencies correct and non-circular (as I
> said, you'll have to do a lot of work to get around it). As long as
> you have anything resembling magically changing models in your
> project, you're not going to be able to use anything makemigrations
> outputs and expect it to Just Work™.
>
> Andrew
>
> On Tuesday, November 4, 2014 3:59:23 PM UTC-8, Carl Meyer wrote:
>
> Hi Justin,
>
> On 11/04/2014 04:42 PM, Justin Myles Holmes wrote:
> >> I don't understand this use case. A ForeignKey impacts only one
> database
> > table's schema; the table for the model on which the ForeignKey
> field is
> > located. The schema of the model the ForeignKey points to
> doesn't need
> > to change at all based on the presence or absence of some other
> > ForeignKey pointing to it.
> >
> > Example:
> >
> > Two apps: apps.coconuts and apps.swallows, each with a canonical
> model
> > (Coconut and Swallow, respectively).
> >
> > The organization runs two version of the project: one with
> apps.swallows
> > and one without.
> >
> > The one with apps.swallows needs a field on Coconut, "carried,"
> which is
> > a FK -=> Swallow.
>
> This is basically the same use case as the Mezzanine one - it's
> attempting to make a model more "reusable" by monkeypatching it with
> additional fields from outside. I think this should be avoided and
> discouraged, not better supported.
>
> The specifics of how to avoid would depend on details of the case,
> but I
> would look towards providing the reusable portions of the model as an
> abstract base, and maybe additionally using swappable models if other
> models need to have an FK to the "extendable" model.
>
> (Swappable models aren't yet formally supported for use outside
> contrib.auth, and there are still rough edges in migration's
> support for
> them, but I think moving them towards formal support is a much better
> answer to this general use case than monkeypatching fields onto
> models.)
>
> Another possibility (which I still don't like, but is better than
> monkeypatching) might be to conditionally define the Coconut.carried
> field, depending on the value of a setting. In that case, the right
> solution for migrations is to still define the migration that adds
> the
> Coconut.carried field in the coconuts app, but make it
> conditionally a
> no-op migration based on the value of the same setting.
>
> > To me, the proper way to do this is to ship a migration in the
> swallows
> > app which adds this field to apps.coconuts.models.Coconut.
>
> Sorry, I don't agree that there's anything "proper" about that :-)
> The
> migration is a secondary issue here - the basic problem is that
> you're
> monkeypatching the Coconut model, and I don't think migrations should
> support/encourage one app monkeypatching another app's models.
>
> > This is certainly a rare use case, but not a special case.  On
> the other
> > hand, I don't see the advantage of restricting the models which
> may be
> > migrated to those in the app in which the migration appears,
> > particularly now that migration dependencies are more
> straightforward.
>
> It's a straightforward issue of encapsulation. The database schema
> for
> the models in app X is the responsibility of app X, not app Y. So far
> the only reasons I've seen why app Y might want to run a migration
> on an
> app-X model is because app Y is monkeypatching that model, to which I
> think the correct response is "don't do 

How do I migrate models from one app to another with django 1.7 migrations?

[Andy Kish]

Hi gang,

I'm trying to refactor the apps in my project, and I can't figure out any 
clean way to migrate models with their data from one app to another. I'm 
really looking for answers to two questions:

1. Is there any canonical way to do this?

2. I've moved my models to the new app but I have them using the tables 
from the old app using Meta.db_table. How do I make migrations understand 
what's going on and not try to delete my old tables? Once migrations gets 
what's going on, how do I rename the old table so it fits the new app name 
so I no longer need Meta.db_table?

--

For question 1. I'm really surprised there isn't a good way to do this. I 
mean—this is kind of a blatant use case for a migration—moving a model from 
one app to another.

My initial thought was to use a use a three phase migration. Create new 
models, copy data over, delete old models. But I'd really rather not 'cause 
the models are all very interconnected and that seems like a recipe for a 
foreign key disaster.

What I actually went with was to move all the models over to the new app, 
and then point them at the old tables using Meta.db_table. Everything 
works, but when I run makemigrations it is confused as crap and wants to 
destroy everything, which brings me to question 2...

---

So question 2, now that I have my model code in a new app pointing at the 
old tables, how do I get the tables renamed to use canonical table names 
and let migrations know wtf is going on?

With the current situation, if I run makemigrations it does something like 
this

Migrations for 'new_app':
  0001_initial.py:
- Create model Building
...
- Add field contact to building
...
Migrations for 'old_app':
  0006_auto_delete_blah.py:
- Remove field contact from building
...
- Delete model Building

...


all of which is roughly correct, just doesn't keep my data intact. :P

My gameplan (*please *correct me if any of this is wrong) is to:

1. Fake the ('new_app', '0001_initial') migration.
2. Make a new data migration depending on ('new_app', '0001_initial') and 
the ('old_app', '0005_...') that uses AlterModelTable 

 to 
rename the tables to their canonical names as would normally be created by 
the 0001_initial migration.
3. Fake the ('old_app', '0006_auto_delete_blah')migration.
4. Get rid of the Meta.db_table entries so my moved models just use the 
normal table names they're supposed to.

Seems like it should get me to where I want to go.


Am I smoking crack? Is this really that hard?


Thanks!
Andy.

-- 
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/63151710-6cde-429b-9af7-09de397704cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A migration in one app that adds a field to another

[Andrew Godwin]

Carl is right that this isn't a supported thing; Django models are designed 
to be static, and not mutate based on settings.

Migrations are designed to only support one linear change history of 
models; swappable models are just about supported but not perfect and leads 
to issues. Adding in the ability to change or remove other fields based on 
installed models is kind of against the way migrations is designed and 
you'll have to do a lot of work to get around it.

In this particular case, it's possible to make it work, but you'll have to 
subclass every one of the actions you want to use and provide a way to 
override the app_label it operates on, and manually construct the 
migrations to get the dependencies correct and non-circular (as I said, 
you'll have to do a lot of work to get around it). As long as you have 
anything resembling magically changing models in your project, you're not 
going to be able to use anything makemigrations outputs and expect it to 
Just Work™.

Andrew

On Tuesday, November 4, 2014 3:59:23 PM UTC-8, Carl Meyer wrote:
>
> Hi Justin, 
>
> On 11/04/2014 04:42 PM, Justin Myles Holmes wrote: 
> >> I don't understand this use case. A ForeignKey impacts only one 
> database 
> > table's schema; the table for the model on which the ForeignKey field is 
> > located. The schema of the model the ForeignKey points to doesn't need 
> > to change at all based on the presence or absence of some other 
> > ForeignKey pointing to it. 
> > 
> > Example: 
> > 
> > Two apps: apps.coconuts and apps.swallows, each with a canonical model 
> > (Coconut and Swallow, respectively). 
> > 
> > The organization runs two version of the project: one with apps.swallows 
> > and one without. 
> > 
> > The one with apps.swallows needs a field on Coconut, "carried," which is 
> > a FK -=> Swallow. 
>
> This is basically the same use case as the Mezzanine one - it's 
> attempting to make a model more "reusable" by monkeypatching it with 
> additional fields from outside. I think this should be avoided and 
> discouraged, not better supported. 
>
> The specifics of how to avoid would depend on details of the case, but I 
> would look towards providing the reusable portions of the model as an 
> abstract base, and maybe additionally using swappable models if other 
> models need to have an FK to the "extendable" model. 
>
> (Swappable models aren't yet formally supported for use outside 
> contrib.auth, and there are still rough edges in migration's support for 
> them, but I think moving them towards formal support is a much better 
> answer to this general use case than monkeypatching fields onto models.) 
>
> Another possibility (which I still don't like, but is better than 
> monkeypatching) might be to conditionally define the Coconut.carried 
> field, depending on the value of a setting. In that case, the right 
> solution for migrations is to still define the migration that adds the 
> Coconut.carried field in the coconuts app, but make it conditionally a 
> no-op migration based on the value of the same setting. 
>
> > To me, the proper way to do this is to ship a migration in the swallows 
> > app which adds this field to apps.coconuts.models.Coconut. 
>
> Sorry, I don't agree that there's anything "proper" about that :-) The 
> migration is a secondary issue here - the basic problem is that you're 
> monkeypatching the Coconut model, and I don't think migrations should 
> support/encourage one app monkeypatching another app's models. 
>
> > This is certainly a rare use case, but not a special case.  On the other 
> > hand, I don't see the advantage of restricting the models which may be 
> > migrated to those in the app in which the migration appears, 
> > particularly now that migration dependencies are more straightforward. 
>
> It's a straightforward issue of encapsulation. The database schema for 
> the models in app X is the responsibility of app X, not app Y. So far 
> the only reasons I've seen why app Y might want to run a migration on an 
> app-X model is because app Y is monkeypatching that model, to which I 
> think the correct response is "don't do that," not "Django should better 
> support that." 
>
> >> I also wonder if there might be a way to do (2) without the 
> > monkeypatching. That is, could Mezzanine provide an importable Operation 
> > subclass for this purpose and document how to import and use it in a 
> > migration? 
> > 
> > Well, the problem there is that Operation isn't used directly, but 
> > subclassed for each individual type of migration operation. 
>
> But for the specific Mezzanine use case, there are really only a few 
> relevant migration operations, right? Seems like add-column, 
> alter-column, and drop-column would cover it. 
>
> Carl 
>
>

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

Re: A migration in one app that adds a field to another

[Carl Meyer]

Hi Justin,

On 11/04/2014 04:42 PM, Justin Myles Holmes wrote:
>> I don't understand this use case. A ForeignKey impacts only one database
> table's schema; the table for the model on which the ForeignKey field is
> located. The schema of the model the ForeignKey points to doesn't need
> to change at all based on the presence or absence of some other
> ForeignKey pointing to it.
> 
> Example:
> 
> Two apps: apps.coconuts and apps.swallows, each with a canonical model
> (Coconut and Swallow, respectively).
> 
> The organization runs two version of the project: one with apps.swallows
> and one without.
> 
> The one with apps.swallows needs a field on Coconut, "carried," which is
> a FK -=> Swallow.

This is basically the same use case as the Mezzanine one - it's
attempting to make a model more "reusable" by monkeypatching it with
additional fields from outside. I think this should be avoided and
discouraged, not better supported.

The specifics of how to avoid would depend on details of the case, but I
would look towards providing the reusable portions of the model as an
abstract base, and maybe additionally using swappable models if other
models need to have an FK to the "extendable" model.

(Swappable models aren't yet formally supported for use outside
contrib.auth, and there are still rough edges in migration's support for
them, but I think moving them towards formal support is a much better
answer to this general use case than monkeypatching fields onto models.)

Another possibility (which I still don't like, but is better than
monkeypatching) might be to conditionally define the Coconut.carried
field, depending on the value of a setting. In that case, the right
solution for migrations is to still define the migration that adds the
Coconut.carried field in the coconuts app, but make it conditionally a
no-op migration based on the value of the same setting.

> To me, the proper way to do this is to ship a migration in the swallows
> app which adds this field to apps.coconuts.models.Coconut.

Sorry, I don't agree that there's anything "proper" about that :-) The
migration is a secondary issue here - the basic problem is that you're
monkeypatching the Coconut model, and I don't think migrations should
support/encourage one app monkeypatching another app's models.

> This is certainly a rare use case, but not a special case.  On the other
> hand, I don't see the advantage of restricting the models which may be
> migrated to those in the app in which the migration appears,
> particularly now that migration dependencies are more straightforward.

It's a straightforward issue of encapsulation. The database schema for
the models in app X is the responsibility of app X, not app Y. So far
the only reasons I've seen why app Y might want to run a migration on an
app-X model is because app Y is monkeypatching that model, to which I
think the correct response is "don't do that," not "Django should better
support that."

>> I also wonder if there might be a way to do (2) without the
> monkeypatching. That is, could Mezzanine provide an importable Operation
> subclass for this purpose and document how to import and use it in a
> migration?
> 
> Well, the problem there is that Operation isn't used directly, but
> subclassed for each individual type of migration operation. 

But for the specific Mezzanine use case, there are really only a few
relevant migration operations, right? Seems like add-column,
alter-column, and drop-column would cover it.

Carl



signature.asc
Description: OpenPGP digital signature

Re: A migration in one app that adds a field to another

[Justin Myles Holmes]

> I don't understand this use case. A ForeignKey impacts only one database
table's schema; the table for the model on which the ForeignKey field is
located. The schema of the model the ForeignKey points to doesn't need
to change at all based on the presence or absence of some other
ForeignKey pointing to it.

Example:

Two apps: apps.coconuts and apps.swallows, each with a canonical model
(Coconut and Swallow, respectively).

The organization runs two version of the project: one with apps.swallows
and one without.

The one with apps.swallows needs a field on Coconut, "carried," which is
a FK -=> Swallow.

To me, the proper way to do this is to ship a migration in the swallows
app which adds this field to apps.coconuts.models.Coconut.

This is certainly a rare use case, but not a special case.  On the other
hand, I don't see the advantage of restricting the models which may be
migrated to those in the app in which the migration appears,
particularly now that migration dependencies are more straightforward.

> I also wonder if there might be a way to do (2) without the
monkeypatching. That is, could Mezzanine provide an importable Operation
subclass for this purpose and document how to import and use it in a
migration?

Well, the problem there is that Operation isn't used directly, but
subclassed for each individual type of migration operation. 


On 11/04/2014 03:33 PM, Carl Meyer wrote:



> Hi Justin,
>
> On 11/04/2014 04:17 PM, Justin Myles Holmes wrote:
>> Hey Carl.  Missed you so very much at DjangoCon.  :-)
> Thanks :-)
>
>>> I'm not sure why the mezzanine docs don't mention using the
>> SOUTH_MIGRATION_MODULES setting (or Django 1.7 equivalent
>> MIGRATION_MODULES) to override the location of the mezzanine app's
>> migrations to a package in your project, where you can freely add custom
>> migrations without modifying mezzanine code.
>>
>> While I don't want to speak for Mezzanine (and, frankly, am not crazy
>> about their approach to field injection in the first place), I surmise
>> that they want to be able to both ship their own migrations (when their
>> models change) and allow their users to add their own migrations (for
>> injecting fields).
>>
>> As I say, I don't love the solution, but I do see its advantages over
>> merely providing a mixin, as they have a relationship structure of their
>> own between their models that they want to maintain.
>>
>> You say that it's a reasonable tradeoff; I don't think I agree.  For
>> Django's part, I'm not convinced that, without exception, migrations for
>> a particular model belong in the same app as that model.  I think there
>> are reasonable times to place them elsewhere, and this is one of them. 
>> Another is an occasion in which an organization has its own internal
>> apps and runs versions of its project without and without a particular
>> app.  If that app requires an incoming ForeignKey from a model in a
>> different app, that migration is ideally only implied in the presence of
>> the target app.
> I don't understand this use case. A ForeignKey impacts only one database
> table's schema; the table for the model on which the ForeignKey field is
> located. The schema of the model the ForeignKey points to doesn't need
> to change at all based on the presence or absence of some other
> ForeignKey pointing to it.
>
> It still seems to me that there isn't a good reason for Django to
> support migrations that modify the schema of a model in some other app.
> That's the migrations equivalent of monkeypatching, and I think it will
> usually end in tears :-)
>
>>> I don't see any monkeypatch there, just subclassing, which is not the same 
>>> thing. I'd say that
>> looks like a very nice solution to the problem. The level of "fiddling
>> with internals" required seems roughly proportional to the peculiarity
>> of the use case; I doubt you'll find anything better (other than perhaps
>> avoiding the problem entirely by using MIGRATION_MODULES).
>>
>> I was unclear: What I meant was that a potential solution within the
>> Mezzanine codebase is a monkeypatch which changes the state_forwards
>> method at runtime to comport with the subclass example that I've provided.
> Ah, I see. I didn't realize that you were looking for a generic solution
> in Mezzanine, rather than a solution for your specific Mezzanine-using
> project.
>
>> My question (which at this point probably belongs more on dev than here)
>> is: Which is the most Djangoic approach:
>>
>> 1) Modify the Mezzanine docs to encourage users to take their own
>> action, such as A) using MIGRATION_MODULES or B) manually editing
>> migrations and subclassing the operation in question as I've done
>> 2) Adding a monkeypatch to Mezzanine which automates solution 1B above
>> (ie, a function that takes an Operation object and returns a
>> OperationOnAnotherApp object)
>> 3) Providing a solution in Django for migrating a model from an app
>> other than that model's home
> I think (2) is right out, and as I said

Re: A migration in one app that adds a field to another

[Justin Myles Holmes]

> I don't understand this use case. A ForeignKey impacts only one database
table's schema; the table for the model on which the ForeignKey field is
located. The schema of the model the ForeignKey points to doesn't need
to change at all based on the presence or absence of some other
ForeignKey pointing to it.

Example:

Two apps: apps.coconuts and apps.swallows, each with a canonical model
(Coconut and Swallow, respectively).

The organization runs two version of the project: one with apps.swallows
and one without.

The one with apps.swallows needs a field on Coconut, "carried," which is
a FK -=> Swallow.

To me, the proper way to do this is to ship a migration in the swallows
app which adds this field to apps.coconuts.models.Coconut.

This is certainly a rare use case, but not a special case.  On the other
hand, I don't see the advantage of restricting the models which may be
migrated to those in the app in which the migration appears,
particularly now that migration dependencies are more straightforward.

>

I also wonder if there might be a way to do (2) without
the monkeypatching. That is, could Mezzanine provide an importable
Operation subclass for this purpose and document how to import and use
it in a migration?


On 11/04/2014 03:33 PM, Carl Meyer wrote:
> Hi Justin,
>
> On 11/04/2014 04:17 PM, Justin Myles Holmes wrote:
>> Hey Carl.  Missed you so very much at DjangoCon.  :-)
> Thanks :-)
>
>>> I'm not sure why the mezzanine docs don't mention using the
>> SOUTH_MIGRATION_MODULES setting (or Django 1.7 equivalent
>> MIGRATION_MODULES) to override the location of the mezzanine app's
>> migrations to a package in your project, where you can freely add custom
>> migrations without modifying mezzanine code.
>>
>> While I don't want to speak for Mezzanine (and, frankly, am not crazy
>> about their approach to field injection in the first place), I surmise
>> that they want to be able to both ship their own migrations (when their
>> models change) and allow their users to add their own migrations (for
>> injecting fields).
>>
>> As I say, I don't love the solution, but I do see its advantages over
>> merely providing a mixin, as they have a relationship structure of their
>> own between their models that they want to maintain.
>>
>> You say that it's a reasonable tradeoff; I don't think I agree.  For
>> Django's part, I'm not convinced that, without exception, migrations for
>> a particular model belong in the same app as that model.  I think there
>> are reasonable times to place them elsewhere, and this is one of them. 
>> Another is an occasion in which an organization has its own internal
>> apps and runs versions of its project without and without a particular
>> app.  If that app requires an incoming ForeignKey from a model in a
>> different app, that migration is ideally only implied in the presence of
>> the target app.
> I don't understand this use case. A ForeignKey impacts only one database
> table's schema; the table for the model on which the ForeignKey field is
> located. The schema of the model the ForeignKey points to doesn't need
> to change at all based on the presence or absence of some other
> ForeignKey pointing to it.
>
> It still seems to me that there isn't a good reason for Django to
> support migrations that modify the schema of a model in some other app.
> That's the migrations equivalent of monkeypatching, and I think it will
> usually end in tears :-)
>
>>> I don't see any monkeypatch there, just subclassing, which is not the same 
>>> thing. I'd say that
>> looks like a very nice solution to the problem. The level of "fiddling
>> with internals" required seems roughly proportional to the peculiarity
>> of the use case; I doubt you'll find anything better (other than perhaps
>> avoiding the problem entirely by using MIGRATION_MODULES).
>>
>> I was unclear: What I meant was that a potential solution within the
>> Mezzanine codebase is a monkeypatch which changes the state_forwards
>> method at runtime to comport with the subclass example that I've provided.
> Ah, I see. I didn't realize that you were looking for a generic solution
> in Mezzanine, rather than a solution for your specific Mezzanine-using
> project.
>
>> My question (which at this point probably belongs more on dev than here)
>> is: Which is the most Djangoic approach:
>>
>> 1) Modify the Mezzanine docs to encourage users to take their own
>> action, such as A) using MIGRATION_MODULES or B) manually editing
>> migrations and subclassing the operation in question as I've done
>> 2) Adding a monkeypatch to Mezzanine which automates solution 1B above
>> (ie, a function that takes an Operation object and returns a
>> OperationOnAnotherApp object)
>> 3) Providing a solution in Django for migrating a model from an app
>> other than that model's home
> I think (2) is right out, and as I said above, I don't think this is a
> use case Django should cover, which means (3) is out too. That leaves
> (1)... although I also wo

Re: A migration in one app that adds a field to another

[Carl Meyer]

Hi Justin,

On 11/04/2014 04:17 PM, Justin Myles Holmes wrote:
> Hey Carl.  Missed you so very much at DjangoCon.  :-)

Thanks :-)

>> I'm not sure why the mezzanine docs don't mention using the
> SOUTH_MIGRATION_MODULES setting (or Django 1.7 equivalent
> MIGRATION_MODULES) to override the location of the mezzanine app's
> migrations to a package in your project, where you can freely add custom
> migrations without modifying mezzanine code.
> 
> While I don't want to speak for Mezzanine (and, frankly, am not crazy
> about their approach to field injection in the first place), I surmise
> that they want to be able to both ship their own migrations (when their
> models change) and allow their users to add their own migrations (for
> injecting fields).
> 
> As I say, I don't love the solution, but I do see its advantages over
> merely providing a mixin, as they have a relationship structure of their
> own between their models that they want to maintain.
> 
> You say that it's a reasonable tradeoff; I don't think I agree.  For
> Django's part, I'm not convinced that, without exception, migrations for
> a particular model belong in the same app as that model.  I think there
> are reasonable times to place them elsewhere, and this is one of them. 
> Another is an occasion in which an organization has its own internal
> apps and runs versions of its project without and without a particular
> app.  If that app requires an incoming ForeignKey from a model in a
> different app, that migration is ideally only implied in the presence of
> the target app.

I don't understand this use case. A ForeignKey impacts only one database
table's schema; the table for the model on which the ForeignKey field is
located. The schema of the model the ForeignKey points to doesn't need
to change at all based on the presence or absence of some other
ForeignKey pointing to it.

It still seems to me that there isn't a good reason for Django to
support migrations that modify the schema of a model in some other app.
That's the migrations equivalent of monkeypatching, and I think it will
usually end in tears :-)

>> I don't see any monkeypatch there, just subclassing, which is not the same 
>> thing. I'd say that
> looks like a very nice solution to the problem. The level of "fiddling
> with internals" required seems roughly proportional to the peculiarity
> of the use case; I doubt you'll find anything better (other than perhaps
> avoiding the problem entirely by using MIGRATION_MODULES).
> 
> I was unclear: What I meant was that a potential solution within the
> Mezzanine codebase is a monkeypatch which changes the state_forwards
> method at runtime to comport with the subclass example that I've provided.

Ah, I see. I didn't realize that you were looking for a generic solution
in Mezzanine, rather than a solution for your specific Mezzanine-using
project.

> My question (which at this point probably belongs more on dev than here)
> is: Which is the most Djangoic approach:
> 
> 1) Modify the Mezzanine docs to encourage users to take their own
> action, such as A) using MIGRATION_MODULES or B) manually editing
> migrations and subclassing the operation in question as I've done
> 2) Adding a monkeypatch to Mezzanine which automates solution 1B above
> (ie, a function that takes an Operation object and returns a
> OperationOnAnotherApp object)
> 3) Providing a solution in Django for migrating a model from an app
> other than that model's home

I think (2) is right out, and as I said above, I don't think this is a
use case Django should cover, which means (3) is out too. That leaves
(1)... although I also wonder if there might be a way to do (2) without
the monkeypatching. That is, could Mezzanine provide an importable
Operation subclass for this purpose and document how to import and use
it in a migration?

Carl

-- 
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/5459625F.8020701%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: A migration in one app that adds a field to another

[Justin Myles Holmes]

Hey Carl.  Missed you so very much at DjangoCon.  :-)

> I'm not sure why the mezzanine docs don't mention using the
SOUTH_MIGRATION_MODULES setting (or Django 1.7 equivalent
MIGRATION_MODULES) to override the location of the mezzanine app's
migrations to a package in your project, where you can freely add custom
migrations without modifying mezzanine code.

While I don't want to speak for Mezzanine (and, frankly, am not crazy
about their approach to field injection in the first place), I surmise
that they want to be able to both ship their own migrations (when their
models change) and allow their users to add their own migrations (for
injecting fields).

As I say, I don't love the solution, but I do see its advantages over
merely providing a mixin, as they have a relationship structure of their
own between their models that they want to maintain.

You say that it's a reasonable tradeoff; I don't think I agree.  For
Django's part, I'm not convinced that, without exception, migrations for
a particular model belong in the same app as that model.  I think there
are reasonable times to place them elsewhere, and this is one of them. 
Another is an occasion in which an organization has its own internal
apps and runs versions of its project without and without a particular
app.  If that app requires an incoming ForeignKey from a model in a
different app, that migration is ideally only implied in the presence of
the target app.

> I don't see any monkeypatch there, just subclassing, which is not the same 
> thing. I'd say that
looks like a very nice solution to the problem. The level of "fiddling
with internals" required seems roughly proportional to the peculiarity
of the use case; I doubt you'll find anything better (other than perhaps
avoiding the problem entirely by using MIGRATION_MODULES).

I was unclear: What I meant was that a potential solution within the
Mezzanine codebase is a monkeypatch which changes the state_forwards
method at runtime to comport with the subclass example that I've provided.

My question (which at this point probably belongs more on dev than here)
is: Which is the most Djangoic approach:

1) Modify the Mezzanine docs to encourage users to take their own
action, such as A) using MIGRATION_MODULES or B) manually editing
migrations and subclassing the operation in question as I've done
2) Adding a monkeypatch to Mezzanine which automates solution 1B above
(ie, a function that takes an Operation object and returns a
OperationOnAnotherApp object)
3) Providing a solution in Django for migrating a model from an app
other than that model's home

On 11/01/2014 09:16 PM, Carl Meyer wrote:
> Hi jMyles,
>
> On 11/01/2014 04:35 PM, jMyles Holmes wrote:
>> Using Django 1.7, how can the user perform a migration operation (say,
>> AddField) on an app other than the app in which the migration lives?
>>
>> Here's the use case:
>>
>> Mezzanine lets you inject fields on its own stock models using the
>> EXTRA_MODEL_FIELDS setting.
>>
>> However, as the Mezzanine docs point out
>>
(http://mezzanine.jupo.org/docs/model-customization.html#field-injection-caveats),
>> there are some "caveats" regarding migrations.
>>
>> Specifically, the migrations need to be placed in a local app even
>> though they're applied to the Mezzanine models.
>>
>> What's the proper way to do this in Django 1.7?
>
> Perhaps someone with more experience with the new migrations system can
> correct me, but I doubt there is a "proper way" - this is an unusual and
> probably unsupported use case that I would guess was never envisioned in
> the design. In general, changes to a model belong in the migrations for
> that model's app.
>
> I'm not sure why the mezzanine docs don't mention using the
> SOUTH_MIGRATION_MODULES setting (or Django 1.7 equivalent
> MIGRATION_MODULES) to override the location of the mezzanine app's
> migrations to a package in your project, where you can freely add custom
> migrations without modifying mezzanine code.
>
> The downside of this approach is that if a new mezzanine version in the
> future ships migrations for changes to their model, you'll have to copy
> or regenerate those migrations yourself in your custom migrations
> directory. That seems like a reasonable tradeoff in the situation where
> you're effectively monkeypatching another app's models.
>
>> It's easy to do it with a monkeypatch.  Here's an example:
>>
>> https://gist.github.com/jMyles/130050563ba96a7d7cc8
>
> I don't see any monkeypatch there, just subclassing, which is not the
> same thing. I'd say that looks like a very nice solution to the problem.
> The level of "fiddling with internals" required seems roughly
> proportional to the peculiarity of the use case; I doubt you'll find
> anything better (other than perhaps avoiding the problem entirely by
> using MIGRATION_MODULES).
>
> Carl
>


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiv

Re: urlize filter does not handle trailing 'dot-dot-dot' correctly

[Russell Keith-Magee]

Hi Will,

If you want to know if a problem has been reported before, the place to
start is the ticket tracker: here's a search of all tickets that mention
urlize:

https://code.djangoproject.com/search?q=urlize&noquickjump=1&ticket=on

>From a quick scan, I can't spot anything related to ellipses; there's a
recent ticket related to exclamation marks, though:

https://code.djangoproject.com/ticket/23715

which would suggest that there is a known subclass of punctuation-related
issues. If you've got a case that reliably breaks (which it sounds like you
do), open a ticket describing the exact problem, and if you're really
adventurous, try your hand at a patch and pull request. The full guidelines
for contributing can be found here:

https://docs.djangoproject.com/en/1.7/internals/contributing/

Yours,
Russ Magee %-)


On Wed, Nov 5, 2014 at 12:13 AM,  wrote:

> Hi, new guy around here.
>
> I am an engineer for a startup (www.agolo.com, check us out :P). We work
> heavily with twitter content, and i've discovered that the urlize template
> tag/filter does not handle trailing 'dot-dot-dot' (which is common in tweet
> content due to all the truncation and whatnot) correctly, since it assume
> that the url can only have 1 trailing punctuation character. should I open
> a pull request for this, or was this problem raised before?
>
> regards,
> Will
>
> --
> 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/85845fcb-606a-40b2-8df1-97afc6d4f1fd%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq848G13i54%3DgtveatVR%2Bv8D7JsTOXTHXWJyxJrwT6%2BDhfMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: urlize filter does not handle trailing 'dot-dot-dot' correctly

[Aliane Abdelouahab]

you can base64 encode it, and decode it after (as a temporary solution)

Le mardi 4 novembre 2014 17:13:33 UTC+1, wi...@agolo.com a écrit :
>
> Hi, new guy around here.
>
> I am an engineer for a startup (www.agolo.com, check us out :P). We work 
> heavily with twitter content, and i've discovered that the urlize template 
> tag/filter does not handle trailing 'dot-dot-dot' (which is common in tweet 
> content due to all the truncation and whatnot) correctly, since it assume 
> that the url can only have 1 trailing punctuation character. should I open 
> a pull request for this, or was this problem raised before?
>
> regards,
> Will
>

-- 
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/9f53ec16-dc8d-412f-9370-92803e3a6ea2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Aw: Re: Beginner: ManyToManyFields error creating the model / adding values by the Admin Module or the Shell

[lnzy35en]

 

Hi Erik,

 

the idea was, that one Author can write in more than one language (eg. en and de), or no one at all. This was the background to use the ManyToManyField. 

But the "error" Message must have an other reason?

 

Best Regards,

Mike


Gesendet: Dienstag, 04. November 2014 um 22:42 Uhr
Von: "Erik Cederstrand" 
An: "Django Users" 
Betreff: Re: Beginner: ManyToManyFields error creating the model / adding values by the Admin Module or the Shell

> Den 04/11/2014 kl. 19.16 skrev lnzy3...@gmx.de:
>
> Hi,
> Sorry, via the admin interface (Web-GUI) I have inserted the following values:
> My Actions
> en
> Language
>
> mike.test // t...@test.de
> User
>
> Dan Brown
> Author
>
> If I now try to add an Interest (“Dan Brown” and “en”) via the GUI selection I get:
> TypeError at /admin/BookReminder/interest/add/
> sequence item 0: expected string,ManyRelatedManager found

It looks like the Interest model is supposed to connect one author with one language. In that case, the fields the Interest class should be models.ForeignKey, not models.ManyToManyField.

Erik

--
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/4736339F-EEBA-41C6-B9E7-D12B161A0B46%40cederstrand.dk.
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/trinity-c759f3ff-0ab7-478c-8506-c7970ec28c5b-1415138875916%403capp-gmx-bs48.
For more options, visit https://groups.google.com/d/optout.

Re: Beginner: ManyToManyFields error creating the model / adding values by the Admin Module or the Shell

[Erik Cederstrand]

> Den 04/11/2014 kl. 19.16 skrev lnzy3...@gmx.de:
> 
> Hi,
> Sorry, via the admin interface (Web-GUI) I have inserted the following values:
> My Actions
> en
> Language
> 
> mike.test // t...@test.de
> User
> 
> Dan Brown
> Author
> 
> If I now try to add an Interest (“Dan Brown” and “en”) via the GUI selection 
> I get:
> TypeError at /admin/BookReminder/interest/add/
> sequence item 0: expected string,ManyRelatedManager found

It looks like the Interest model is supposed to connect one author with one 
language. In that case, the fields the Interest class should be 
models.ForeignKey, not models.ManyToManyField.

Erik

-- 
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/4736339F-EEBA-41C6-B9E7-D12B161A0B46%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Development using django: wireframes enough to begin?

[Mike Dewhirst]

On 5/11/2014 3:04 AM, Dave wrote:

I'm trying to understand how using django for development works. Can a
backend developer begin with just a wireframe?


Yes. Start with your models and give them methods and fields you know 
will be needed. Importantly you should write unit tests to prove your 
methods do what is intended. Then write a clean() method for each model 
to carry as much business validation logic as you can. Raise your own 
business rule violation exceptions as required.


You don't even need a live database. By that I mean it isn't necessary 
to "manage.py syncdb" to create your database (don't know about Django 
1.7 here - I'm using 1.6) because when you run your unit tests 
("manage.py test") the test database is created from your models not 
copied from the real database.


You can't get any more "wireframe" than that.

At some stage you will have to introduce html if you want a website but 
even then, your templates can be very simple until your design team says 
precisely what they want.


Isn't it possible to

develop scripts while someone else is writing the html/css code? (like
working on the front end and back end at the same time)


Yes. I think it is a very good idea to do that. If you know what the 
system will look like before you build the back end it will give proper 
focus to your work.




For example: Creating a forum. Can't the backend develop the features
like creating a community, managing the community and storing the
information in the DB and then once the integration begins, take the
html/css and combine it?


Yes. Django comes with a front end called the Admin. It lets you expose 
your database to the outside world via your models complete with your 
business logic built into your clean() methods. It isn't supposed to 
replace the user interface you design for your users but it lets you 
quickly and easily put essential data into your wireframe.


So yes, there is enough to begin.

Good luck

Mike



--
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/2d084bf3-0c89-4922-a45d-394e19bcbe6f%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/545945A1.7020705%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Beginner: ManyToManyFields error creating the model / adding values by the Admin Module or the Shell

[lnzy35en]

Hi,

Sorry, via the admin interface (Web-GUI) I have inserted the following values:

My Actions

en
Language

mike.test // t...@test.de

User

 

Dan Brown
Author

 

If I now try to add an Interest (“Dan Brown” and “en”) via the GUI selection I get:

TypeError at /admin/BookReminder/interest/add/

sequence item 0: expected string, ManyRelatedManager found


	
		
			
			Request Method:
			
			
			POST
			
		
		
			
			Request URL:
			
			
			http://127.0.0.1:8000/admin/BookReminder/interest/add/
			
		
		
			
			Django Version:
			
			
			1.7
			
		
		
			
			Exception Type:
			
			
			TypeError
			
		
		
			
			Exception Value:
			
			
			sequence item 0: expected string, ManyRelatedManager found
			
		
		
			
			Exception Location:
			
			
			D:\D-Project\SOL\BookReminder\models.py in __str__, line 39
			
		
		
			
			Python Executable:
			
			
			C:\Python27\python.exe
			
		
		
			
			Python Version:
			
			
			2.7.6
			
		
		
			
			Python Path:
			
			
			['D:\\D-Project\\SOL',

			 'C:\\Windows\\system32\\python27.zip',

			 'C:\\Python27\\DLLs',

			 'C:\\Python27\\lib',

			 'C:\\Python27\\lib\\plat-win',

			 'C:\\Python27\\lib\\lib-tk',

			 'C:\\Python27',

			 'C:\\Python27\\lib\\site-packages']
			
		
		
			
			Server time:
			
			
			Tue, 4 Nov 2014 18:48:34 +0100
			
		
	


 

So for me it looks like in the Model there is an error? Otherwise it should work via the GUI that gives me the two fields as input possibilites. The same happens, if I try to add the interesst by using the user in the admin interface and click there on "add" interest.

 

Best Regards,

Mike




-- 
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/trinity-178b3e5e-8e2e-45c0-97f7-158fe3e34fd6-1415124982218%403capp-gmx-bs03.
For more options, visit https://groups.google.com/d/optout.

urlize filter does not handle trailing 'dot-dot-dot' correctly

[will]

Hi, new guy around here.

I am an engineer for a startup (www.agolo.com, check us out :P). We work 
heavily with twitter content, and i've discovered that the urlize template 
tag/filter does not handle trailing 'dot-dot-dot' (which is common in tweet 
content due to all the truncation and whatnot) correctly, since it assume 
that the url can only have 1 trailing punctuation character. should I open 
a pull request for this, or was this problem raised before?

regards,
Will

-- 
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/85845fcb-606a-40b2-8df1-97afc6d4f1fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Development using django: wireframes enough to begin?

[Dave]

I'm trying to understand how using django for development works. Can a 
backend developer begin with just a wireframe? Isn't it possible to develop 
scripts while someone else is writing the html/css code? (like working on 
the front end and back end at the same time)

For example: Creating a forum. Can't the backend develop the features like 
creating a community, managing the community and storing the information in 
the DB and then once the integration begins, take the html/css and combine 
it?

-- 
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/2d084bf3-0c89-4922-a45d-394e19bcbe6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

running unit tests with legacy database: Error 1050, Table already exists

[dpalao . python]

Hello,
I'm relatively new to Django, so it might well be a silly question...
I'm using Django-1.7 with Python-3.3.
I'm working with a legacy MySQL database. I tried both pymysql and 
mysql-connector-python, the errors are similar.

When I run the unit tests, for instance, with mysql-connector-python, I get
python manage.py test jobwatcher
...
mysql.connector.errors.ProgrammingError: 1050 (42S01): Table 'auth_group' 
already exists

During handling of the above exception, another exception occurred:
...
  File 
"/test/virtualenv/lib/python3.3/site-packages/mysql/connector/connection.py"
, line 638, in _handle_result
raise errors.get_exception(packet)
django.db.utils.ProgrammingError: Table 'auth_group' already exists

I read that one has to use the inspectdb command to generate the models 
when working with legacy databases, so I did; and I also set the "managed" 
variale to False in the meta thing. For instance:
class JobMon(models.Model):
id = models.BigIntegerField(primary_key=True)
job_db_inx = models.IntegerField()
value_avg = models.BigIntegerField()
value_sum = models.BigIntegerField()
mon_type = models.IntegerField()
timestamp = models.IntegerField()
is_valid = models.IntegerField()
is_full = models.IntegerField()
nodes_nr = models.IntegerField()

class Meta:
managed = False
db_table = 'job_mon'


I tried different things, but I'm just shooting in the dark right now.

Can anyone give me a hint of whats going on and/or how to solve this 
problem?

TIA,

David

-- 
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/4fdad4c1-b28e-4b4e-91ff-b892ea9289c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Beginner: ManyToManyFields error creating the model / adding values by the Admin Module or the Shell

[Erik Cederstrand]

> Den 04/11/2014 kl. 10.57 skrev lnzy3...@gmx.de:
> [...]
> Now I try to add some User with an Interest using the Admin module or the 
> Shell to find out how to do that (real syntax and model) by the “site”. But 
> unfortunately both the shell and furthermore the graphical admin module give 
> me an error, whenever I try to add the data to an user.
> Where is my error? What do I miss?

Yes, where IS your error? You forgot to attach the error message.

Erik

-- 
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/90467054-B7D6-4339-8D7C-44217E5227E8%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Global Variable

[Sudipta Sen]

By the way I am using virtual environment and my django version is *1.7.1*

-- 
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/e467df84-9b64-4ba6-a8ae-726605e899b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Global Variable

[Andreas Kuhne]

2014-11-04 14:18 GMT+01:00 Sudipta Sen :

>
>
> -- Forwarded message -
> From: Sudipta Sen 
> Date: Tue Nov 04 2014 at 6:46:17 PM
> Subject: Global Variable
> To: 
>
>
> Hi folks,
>
> I am very new to django and facing some problems.
>
> 1. I need a global variable, which I can use throughout the application.
> Like let's say base_url.
>
>- I tried defining one variable in settings and using it places like
>this
>   - from django.conf import settings
>   - url = settings.BASE_URL+'login'
>- This gives me an error : non-keyword arg after keyword arg
>- Also this process seems to be painful, every time I have to import
>settings in each of my views.
>
> 2. I need a custome context variable to be passed everytime.
>
>- I tried this: in the same directory where my settings is, I created
>a context_processors.py
>- context_processors.py:
>- def baseurl(request):
>  - return {"base_url" : "/some/url/"}
>   - In my settings.py file I am adding this line :
>   -
>
>   TEMPLATE_CONTEXT_PROCESSORS += ('context_processors.baseurl',)
>
>   -
>
>   This gives me an error : NameError: name 'TEMPLATE_CONTEXT_PROCESSORS' 
> is not defined
>
>
> Please help me on these issues.
>
> --
> 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/CAO0Um5FCybTFF9BeJn%3DTw755EFsCVhL8TEw14pjQTxnP5muwtA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

Hi Sudipta,

You can do this in one of 2 ways:
1. Add it to your settings file, like you have done. I would however write
: url = "%s/login" % settings.BASE_URL instead.
2. Add a context processor. You should in your settings.py add:
TEMPLATE_CONTEXT_PROCESSORS = (
"django.contrib.auth.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media",
"django.core.context_processors.static",
"django.core.context_processors.tz",
"django.contrib.messages.context_processors.messages",
"django.core.context_processors.request",
"context_processors.baseurl",
)

That includes the normally added context processors (at least those that we
have in our project at the moment).

Regards,

Andréas

-- 
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/CALXYUb%3DmhKbCwppZfaCurW6nc%3DBkJ6-aB2v14UrLoxjq4Zx%3DQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fwd: Global Variable

[Sudipta Sen]

-- Forwarded message -
From: Sudipta Sen 
Date: Tue Nov 04 2014 at 6:46:17 PM
Subject: Global Variable
To: 


Hi folks,

I am very new to django and facing some problems.

1. I need a global variable, which I can use throughout the application.
Like let's say base_url.

   - I tried defining one variable in settings and using it places like
   this
  - from django.conf import settings
  - url = settings.BASE_URL+'login'
   - This gives me an error : non-keyword arg after keyword arg
   - Also this process seems to be painful, every time I have to import
   settings in each of my views.

2. I need a custome context variable to be passed everytime.

   - I tried this: in the same directory where my settings is, I created a
   context_processors.py
   - context_processors.py:
   - def baseurl(request):
 - return {"base_url" : "/some/url/"}
  - In my settings.py file I am adding this line :
  -

  TEMPLATE_CONTEXT_PROCESSORS += ('context_processors.baseurl',)

  -

  This gives me an error : NameError: name
'TEMPLATE_CONTEXT_PROCESSORS' is not defined


Please help me on these issues.

-- 
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/CAO0Um5FCybTFF9BeJn%3DTw755EFsCVhL8TEw14pjQTxnP5muwtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple site package directories for Python and question about apache configuration

[Aliane Abdelouahab]

i dont know how to do that, but the easied way is to just copy the whole 
packages and paste them in only one directory, since python packages are 
just folders/eggs

Le mardi 4 novembre 2014 13:26:12 UTC+1, robert brook a écrit :
>
> I see that there are 2 paths in my application for site packages.
>
> How do I configure Apache to use the 2 packages.
>
> A typical entry in Apache is
>
> WSGIPythonPath 
> /path/to/mysite.com:/path/to/your/venv/lib/python3.X/site-packages
>
> Can I specify 2 paths to represent the 2 locations of site packages.
> And what would the syntax be?
>
> On Monday, November 3, 2014 4:15:59 PM UTC-5, Aliane Abdelouahab wrote:
>>
>> On linux, python installs libs in diffferents places: for example in open 
>> suse, when you install it the first time, and you choose python and some 
>> third party libraries, and then when you will do setup.py for a library you 
>> download, they will be in different locations!
>> http://stackoverflow.com/a/12950101/861487
>>
>> Le lundi 3 novembre 2014 21:24:17 UTC+1, robert brook a écrit :
>>>
>>> I overlooked mentioning that the path command returned 2 different 
>>> locations for the 3 modules.
>>> Not sure why one package got installed in the lib64 path.  They were all 
>>> installed with the setup.py install command.
>>>
>>> On Monday, November 3, 2014 3:18:06 PM UTC-5, robert brook wrote:

 I am building the web application on a linux red hat machine.

 I was trying to pull the path for the site packages for the 3 modules 
 that I have installed so that I can specify the path in the apache config 
 file

 Can I specify 2 paths in Apache?

 Thanks



 >>> import django

 >>> print (django.__path__)

 ['*/opt/rh/python33/root/usr/lib/python3.3/site-packages/*
 Django-1.7-py3.3.egg/django']

  >>> import sql_server.pyodbc

 >>> print (sql_server.pyodbc.__path__)

 ['/opt/rh/python33/root/usr/*lib*
 /python3.3/site-packages/django_pyodbc_azure-1.2.0-py3.3.egg/sql_server/pyodbc']

   

 >>> import sqlalchemy

 >>> print (sqlalchemy.__path__)

 ['/opt/rh/python33/root/usr/*lib64*
 /python3.3/site-packages/SQLAlchemy-0.9.7-py3.3-linux-x86_64.egg/sqlalchemy']

 >>> 

>>>

-- 
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/3965c30f-5f33-455f-89f6-da0ff3f9595a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django1.7, python3.4 and MySQL

[Larry Martell]

Thanks.

On Tue, Nov 4, 2014 at 7:37 AM, Tim Graham  wrote:
> mysqlclient is available here: https://pypi.python.org/pypi/mysqlclient
>
> I just fixed the missing links in Django's database documentation -- sorry
> for the confusion.
>
> On Monday, November 3, 2014 12:56:27 PM UTC-5, larry@gmail.com wrote:
>>
>> On Mon, Nov 3, 2014 at 12:42 PM, Leandro Zanuz  wrote:
>> >
>> > You can download it on mysql official website:
>> >
>> > http://dev.mysql.com/downloads/connector/python/
>>
>> Yes, I know that. I am looking for mysqlclient
>>
>> >
>> >
>> > 2014-11-03 15:10 GMT-02:00 Larry Martell :
>> >>
>> >> On Mon, Nov 3, 2014 at 11:13 AM,   wrote:
>> >> >
>> >> > Yes, mysql-python-connector works fine with python3.4.2.
>> >> >
>> >> > I'm using it and no problems until now.
>> >>
>> >> Thanks for the reply. Do you know where I can download it from?
>> >>
>> >> >
>> >> >
>> >> > Em segunda-feira, 3 de novembro de 2014 13h55min25s UTC-2,
>> >> > larry@gmail.com escreveu:
>> >> >>
>> >> >> So it seems MySQLdb doesn't support python3, and I see this on the
>> >> >> django
>> >> >> site:
>> >> >>
>> >> >> mysqlclient is a fork of MySQLdb which notably supports Python 3 and
>> >> >> can be used as a drop-in replacement for MySQLdb. At the time of
>> >> >> this
>> >> >> writing, this is the recommended choice for using MySQL with Django.
>> >> >>
>> >> >> mysqlclient
>> >> >>
>> >> >> Django requires mysqlclient 1.3.3 or later. Note that Python 3.2 is
>> >> >> not supported. Except for the Python 3.3+ support, mysqlclient
>> >> >> should
>> >> >> mostly behave the same as MySQLDB.
>> >> >>
>> >> >> So does this mean that mysqlclient does support python3.4?
>> >> >>
>> >> >> And how can I download a debian package for that?
>
> --
> 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/2206e256-189c-4689-a04f-8fdeeacc0e20%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACwCsY5jkcvB0MGvN7nAgG5BL%2Bi9%3DmCu2%2BdkcvF_poo0JBAD3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: django1.7, python3.4 and MySQL

[Tim Graham]

mysqlclient is available here: https://pypi.python.org/pypi/mysqlclient

I just fixed the missing links in Django's database documentation -- sorry 
for the confusion.

On Monday, November 3, 2014 12:56:27 PM UTC-5, larry@gmail.com wrote:
>
> On Mon, Nov 3, 2014 at 12:42 PM, Leandro Zanuz  > wrote: 
> > 
> > You can download it on mysql official website: 
> > 
> > http://dev.mysql.com/downloads/connector/python/ 
>
> Yes, I know that. I am looking for mysqlclient 
>
> > 
> > 
> > 2014-11-03 15:10 GMT-02:00 Larry Martell  >: 
> >> 
> >> On Mon, Nov 3, 2014 at 11:13 AM,  > wrote: 
> >> > 
> >> > Yes, mysql-python-connector works fine with python3.4.2. 
> >> > 
> >> > I'm using it and no problems until now. 
> >> 
> >> Thanks for the reply. Do you know where I can download it from? 
> >> 
> >> > 
> >> > 
> >> > Em segunda-feira, 3 de novembro de 2014 13h55min25s UTC-2, 
> >> > larry@gmail.com escreveu: 
> >> >> 
> >> >> So it seems MySQLdb doesn't support python3, and I see this on the 
> >> >> django 
> >> >> site: 
> >> >> 
> >> >> mysqlclient is a fork of MySQLdb which notably supports Python 3 and 
> >> >> can be used as a drop-in replacement for MySQLdb. At the time of 
> this 
> >> >> writing, this is the recommended choice for using MySQL with Django. 
> >> >> 
> >> >> mysqlclient 
> >> >> 
> >> >> Django requires mysqlclient 1.3.3 or later. Note that Python 3.2 is 
> >> >> not supported. Except for the Python 3.3+ support, mysqlclient 
> should 
> >> >> mostly behave the same as MySQLDB. 
> >> >> 
> >> >> So does this mean that mysqlclient does support python3.4? 
> >> >> 
> >> >> And how can I download a debian package for that? 
>

-- 
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/2206e256-189c-4689-a04f-8fdeeacc0e20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple site package directories for Python and question about apache configuration

[robert brook]

I see that there are 2 paths in my application for site packages.

How do I configure Apache to use the 2 packages.

A typical entry in Apache is

WSGIPythonPath 
/path/to/mysite.com:/path/to/your/venv/lib/python3.X/site-packages

Can I specify 2 paths to represent the 2 locations of site packages.
And what would the syntax be?

On Monday, November 3, 2014 4:15:59 PM UTC-5, Aliane Abdelouahab wrote:
>
> On linux, python installs libs in diffferents places: for example in open 
> suse, when you install it the first time, and you choose python and some 
> third party libraries, and then when you will do setup.py for a library you 
> download, they will be in different locations!
> http://stackoverflow.com/a/12950101/861487
>
> Le lundi 3 novembre 2014 21:24:17 UTC+1, robert brook a écrit :
>>
>> I overlooked mentioning that the path command returned 2 different 
>> locations for the 3 modules.
>> Not sure why one package got installed in the lib64 path.  They were all 
>> installed with the setup.py install command.
>>
>> On Monday, November 3, 2014 3:18:06 PM UTC-5, robert brook wrote:
>>>
>>> I am building the web application on a linux red hat machine.
>>>
>>> I was trying to pull the path for the site packages for the 3 modules 
>>> that I have installed so that I can specify the path in the apache config 
>>> file
>>>
>>> Can I specify 2 paths in Apache?
>>>
>>> Thanks
>>>
>>>
>>>
>>> >>> import django
>>>
>>> >>> print (django.__path__)
>>>
>>> ['*/opt/rh/python33/root/usr/lib/python3.3/site-packages/*
>>> Django-1.7-py3.3.egg/django']
>>>
>>>  >>> import sql_server.pyodbc
>>>
>>> >>> print (sql_server.pyodbc.__path__)
>>>
>>> ['/opt/rh/python33/root/usr/*lib*
>>> /python3.3/site-packages/django_pyodbc_azure-1.2.0-py3.3.egg/sql_server/pyodbc']
>>>
>>>   
>>>
>>> >>> import sqlalchemy
>>>
>>> >>> print (sqlalchemy.__path__)
>>>
>>> ['/opt/rh/python33/root/usr/*lib64*
>>> /python3.3/site-packages/SQLAlchemy-0.9.7-py3.3-linux-x86_64.egg/sqlalchemy']
>>>
>>> >>> 
>>>
>>

-- 
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/ca460d30-a2be-4133-a69a-248e7e38739e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can Django be used to create a survey website?

[Andreas Kuhne]

2014-11-04 11:23 GMT+01:00 Tobias Dacoir :

> I need to create a survey like website. Users should be able to register
> and then are presented with different images which they are asked questions
> about.
>
> So essentially I have multiple Sets of Images, a set of questions (not all
> questions are valid for all sets of images) and a set of answers. Answers
> can be either pre-filled strings (for example question about gender: male /
> female) or an int value from 0 to 7.
>
> Later on I need to figure out who gave which answers for which image and I
> need to count all answers for a specific question and image combination to
> calculate how many people voted for male for example and give an average
> number as result for other questions.
>
> Is this possible to create with Django? So far I did do the tutorial and
> tried creating my own models and some basic views but I'm having some
> trouble with my model already.
>
>
Hi Tobias,

Yes that is possible. Anything you can do on the Internet is probably
possible in Django. You will of course have to create your own models,
views and templates. You could also search (on google) for a django plugin
that has some of the features that you want (for example:
https://code.google.com/p/django-survey/ could have some features that you
would like?).

Regards,

Andréas

-- 
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/CALXYUbn3kzuLEfy9py3t%3Dc_i2v%2BkPddXCTgymn_Nxz%2BPLAkfSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Beginner: ManyToManyFields error creating the model / adding values by the Admin Module or the Shell

[lnzy35en]

Hi,

Unfortunately I have not found any Intel at the django documentation, in the Getting Started With Django book or the Two Scoops of Django book.  So I hope someone in the community will sacrifice his nerves and time, and gives me a hint / explanation of my misunderstanding.

 

I have the following classes / models in my models.py:

class Author(models.Model):

    author= models.CharField(max_length=255, verbose_name="Author name")

    def __str__(self):

    return self.author

 

class Language(models.Model):

    ENGLISH = 'en'

    GERMAN = 'de'

    FRENCH = 'fr'

    NOT_AVAILABLE = ''

    LANGUAGE_CHOICES = (

    (ENGLISH, 'English'),

    (GERMAN, 'German'),

    (FRENCH, 'French'),

    (NOT_AVAILABLE, ''),

    )

    language = models.CharField(max_length=32,choices=LANGUAGE_CHOICES,default=NOT_AVAILABLE)

    def __str__(self):

    return self.language

 

 

class User(models.Model):

    user_name = models.CharField(max_length=128, verbose_name="Username")

    user_email = models.EmailField(verbose_name="User E-Mail address")

    interests = models.ManyToManyField(Interest, verbose_name="User interessts")

    def __str__(self):

    return ' '.join([

    self.user_name,

    self.user_email])

   

class Interest(models.Model):

    author = models.ManyToManyField(Author, verbose_name="Author name")

    language = models.ManyToManyField(Language, verbose_name="Book language", blank=True)

    def __str__(self):

    return ' '.join([

    self.author,

    self.language])

 

Now I try to add some User with an Interest using the Admin module or the Shell to find out how to do that (real syntax and model) by the “site”. But unfortunately both the shell and furthermore the graphical admin module give me an error, whenever I try to add the data to an user.

Where is my error? What do I miss? My idea is, that every User has (many) Interests and an Interest is defined by an Author who he likes as well as a “possible” language in which he writes.

 

So hopefully someone seas my probably basic-error very fast!

Thank you very much!

Mike



-- 
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/trinity-505e6d99-93e8-4e71-98da-c0de02ff93a8-1415095074268%403capp-gmx-bs71.
For more options, visit https://groups.google.com/d/optout.

Can Django be used to create a survey website?

[Tobias Dacoir]

I need to create a survey like website. Users should be able to register 
and then are presented with different images which they are asked questions 
about. 

So essentially I have multiple Sets of Images, a set of questions (not all 
questions are valid for all sets of images) and a set of answers. Answers 
can be either pre-filled strings (for example question about gender: male / 
female) or an int value from 0 to 7.

Later on I need to figure out who gave which answers for which image and I 
need to count all answers for a specific question and image combination to 
calculate how many people voted for male for example and give an average 
number as result for other questions.

Is this possible to create with Django? So far I did do the tutorial and 
tried creating my own models and some basic views but I'm having some 
trouble with my model already.


-- 
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/740700e9-2206-4e9f-8cb0-42e7096677fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Get form from modelformset by the model associated in template

[Luigi Cirillo]

Yes, thank you Collin

On Monday, November 3, 2014 2:14:53 AM UTC+1, Collin Anderson wrote:
>
> Hi Luigi,
>
> Do you want something like this?
>
> {% for form in modelformset %}
> The object: {{ form.instance }}
> The form: {{ form }}
> {% endform %}}
>
> Collin
>
>

-- 
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/27b3f687-2d9c-47b9-b037-12af991680b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does django use mysqldb over mysql-connector?

[Larry Martell]

Yes, thanks for the link. For some reason google wasn't finding that for me.

On Tue, Nov 4, 2014 at 6:59 AM,   wrote:
>
> Are you talking about this?
>
> https://github.com/PyMySQL/mysqlclient-python
>
> I didn't tried that. Someone use it?
>
>
> Em terça-feira, 4 de novembro de 2014 09h08min38s UTC-2, larry@gmail.com
> escreveu:
>>
>> What about mysqlclient? The django site says that is "the recommended
>> choice for using MySQL with Django" but I can't seem to find that
>> package. Does anyone have a link for that?
>>
>> On Mon, Nov 3, 2014 at 8:57 PM,   wrote:
>> >
>> > Hi all,
>> >
>> > I notice that python-mysql-connector(1) is almost 30% slow that
>> > MySQLdb(2),
>> > but MySQLdb until now not support python3.
>> >
>> > Anyone have news when MySQLdb will support python 3 or know another
>> > connector for mysql?
>> >
>> > It's a litte confused at this time, because we have django1.7.X that
>> > supports python3.4.X very well, but we don't have a good compatible
>> > mysql
>> > connector.
>> >
>> > 1-http://dev.mysql.com/downloads/connector/python/
>> > 2-https://pypi.python.org/pypi/MySQL-python/1.2.5
>> >
>> >
>> > Em quinta-feira, 3 de maio de 2012 22h18min23s UTC-3, john2095 escreveu:
>> >>
>> >> I've just been through a slice of hell simply because I did not want to
>> >> install mysql-server on my (osx) django development machine - my app
>> >> connects to a remote mysql database.  It turns out that python's
>> >> "mysqldb"
>> >> depends on mysql binaries which are only packaged up with the server
>> >> release.  This means that if you want to run django and connect to a
>> >> remote
>> >> mysql you still need to install mysqlserver locally.  I think that
>> >> blows.
>> >> Especially when there is a purely python mysql driver in
>> >> "mysql-connector".
>> >>
>> >> Has this happened by default or by design?  Is mysqldb really that much
>> >> faster, or featureful, or just because it's more common?
>> >>
>> >> Is anyone working on a pure python solution (mysql-connector) database
>> >> backend? Is there one already?
>> >>
>> >> thanks.
>> >
>> >
>> > Enviado via UCSMail.
>> >
>> > --
>> > 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...@googlegroups.com.
>> > To post to this group, send email to django...@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/041bea14-74e6-42ce-b549-8ca5d31344e4%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACwCsY58V2j3dAcvKDqbN4R6vhQ_b_%3Dx3V%3DfxHa9PsUm7BMmDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does django use mysqldb over mysql-connector?

[lzanuz]

Are you talking about this?

https://github.com/PyMySQL/mysqlclient-python

I didn't tried that. Someone use it?


Em terça-feira, 4 de novembro de 2014 09h08min38s UTC-2, 
larry@gmail.com escreveu:
>
> What about mysqlclient? The django site says that is "the recommended 
> choice for using MySQL with Django" but I can't seem to find that 
> package. Does anyone have a link for that? 
>
> On Mon, Nov 3, 2014 at 8:57 PM,  > wrote: 
> > 
> > Hi all, 
> > 
> > I notice that python-mysql-connector(1) is almost 30% slow that 
> MySQLdb(2), 
> > but MySQLdb until now not support python3. 
> > 
> > Anyone have news when MySQLdb will support python 3 or know another 
> > connector for mysql? 
> > 
> > It's a litte confused at this time, because we have django1.7.X that 
> > supports python3.4.X very well, but we don't have a good compatible 
> mysql 
> > connector. 
> > 
> > 1-http://dev.mysql.com/downloads/connector/python/ 
> > 2-https://pypi.python.org/pypi/MySQL-python/1.2.5 
> > 
> > 
> > Em quinta-feira, 3 de maio de 2012 22h18min23s UTC-3, john2095 escreveu: 
> >> 
> >> I've just been through a slice of hell simply because I did not want to 
> >> install mysql-server on my (osx) django development machine - my app 
> >> connects to a remote mysql database.  It turns out that python's 
> "mysqldb" 
> >> depends on mysql binaries which are only packaged up with the server 
> >> release.  This means that if you want to run django and connect to a 
> remote 
> >> mysql you still need to install mysqlserver locally.  I think that 
> blows. 
> >> Especially when there is a purely python mysql driver in 
> "mysql-connector". 
> >> 
> >> Has this happened by default or by design?  Is mysqldb really that much 
> >> faster, or featureful, or just because it's more common? 
> >> 
> >> Is anyone working on a pure python solution (mysql-connector) database 
> >> backend? Is there one already? 
> >> 
> >> thanks. 
> > 
> > 
> > Enviado via UCSMail. 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To post to this group, send email to django...@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/041bea14-74e6-42ce-b549-8ca5d31344e4%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
Enviado via UCSMail.

-- 
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/4a00814f-7bc5-430f-9ebe-aecaee030ed5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does django use mysqldb over mysql-connector?

[Larry Martell]

What about mysqlclient? The django site says that is "the recommended
choice for using MySQL with Django" but I can't seem to find that
package. Does anyone have a link for that?

On Mon, Nov 3, 2014 at 8:57 PM,   wrote:
>
> Hi all,
>
> I notice that python-mysql-connector(1) is almost 30% slow that MySQLdb(2),
> but MySQLdb until now not support python3.
>
> Anyone have news when MySQLdb will support python 3 or know another
> connector for mysql?
>
> It's a litte confused at this time, because we have django1.7.X that
> supports python3.4.X very well, but we don't have a good compatible mysql
> connector.
>
> 1-http://dev.mysql.com/downloads/connector/python/
> 2-https://pypi.python.org/pypi/MySQL-python/1.2.5
>
>
> Em quinta-feira, 3 de maio de 2012 22h18min23s UTC-3, john2095 escreveu:
>>
>> I've just been through a slice of hell simply because I did not want to
>> install mysql-server on my (osx) django development machine - my app
>> connects to a remote mysql database.  It turns out that python's "mysqldb"
>> depends on mysql binaries which are only packaged up with the server
>> release.  This means that if you want to run django and connect to a remote
>> mysql you still need to install mysqlserver locally.  I think that blows.
>> Especially when there is a purely python mysql driver in "mysql-connector".
>>
>> Has this happened by default or by design?  Is mysqldb really that much
>> faster, or featureful, or just because it's more common?
>>
>> Is anyone working on a pure python solution (mysql-connector) database
>> backend? Is there one already?
>>
>> thanks.
>
>
> Enviado via UCSMail.
>
> --
> 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/041bea14-74e6-42ce-b549-8ca5d31344e4%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACwCsY7_qyuZq%2BOFe5y7UTfGhFzJrijhHdr4QcYrG30osOQFYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.