RE : Email on App
Hai , i am have requirement , user need to send email after login into app with login user email where , i tried to send with default but i need to use from email as login user email can any one clear my issue. Thanks Arun -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/44e4b31e-5933-46de-a713-9aa8d0e33fe3n%40googlegroups.com.
How to stop testserver from within a test case?
We have Django 1.6. For a somewhat obscure reason, I need to stop the testserver from within a test case. Any ideas? I would like a programmatic solution if possible. Finding a process and killing it (ps -ef., then grep, then kill) is bit of a hack, and may end up killing unintended processes. Note that I want the testserver stopped for a small number of test cases. For the rest of them, the testserver should be running as it always does. Thanks, Arun -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/422b87d4-f4c2-468b-a4ad-1219f61b96e5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
some suggested code change in Django 1.6.7
This is not a feature request per se, but it is not exactly a bug report
either.
We are recently upgrading from Django 1.5 to Django 1.6.7. One other
relevant package version of interest is psycopg2 which is at 2.5.4.
After upgrade, many test cases were failing with the classic
"InterfaceError: connection already closed" originating from psycopg2. Here
is a typical stack trace in which user-name and app-name have been obscured.
File "/home/user1/sme-appname/src/session_csrf/__init__.py", line 68, in
process_view
token = cache.get(PREFIX + key, '')
File
"/home/user1/sme-appname/lib/python2.7/site-packages/django/core/cache/backends/db.py",
line 61, in get
cursor = connections[db].cursor()
File
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/backends/__init__.py",
line 162, in cursor
cursor = util.CursorWrapper(self._cursor(), self)
File
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/backends/__init__.py",
line 134, in _cursor
return self.create_cursor()
File
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/utils.py",
line 99, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/backends/__init__.py",
line 134, in _cursor
return self.create_cursor()
File
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py",
line 138, in create_cursor
cursor = self.connection.cursor()
InterfaceError: connection already closed
I posted this on psycopg2 mailing list, but was told to contact you Django
guys. Anyway, after tinkering around with some code in the django/db
directory, I generated the following "fix" that helped most of our test
cases to pass. The fix is in two files:
(1) django/db/backends/__init__.py --> comment out the code that compares
two autocommit values.
def close_if_unusable_or_obsolete(self):
"""
Closes the current connection if unrecoverable errors have occurred,
or if it outlived its maximum age.
"""
if self.connection is not None:
# If the application didn't restore the original autocommit
setting,
# don't take chances, drop the connection.
#if self.get_autocommit() != self.settings_dict['AUTOCOMMIT']:
#print(" from within close_if_unusable_or_obsolete
method ")
#print(" two autocommit settings not equal ")
#print(self.get_autocommit())
#print(self.settings_dict['AUTOCOMMIT'])
#self.close()
#return
if self.errors_occurred:
if self.is_usable():
self.errors_occurred = False
else:
print(" from within close_if_unusable_or_obsolete
method ")
self.close()
return
if self.close_at is not None and time.time() >= self.close_at:
print(" from within close_if_unusable_or_obsolete
method ")
self.close()
return
(2) django/db/__init__.py --> simply call the recommended
close_old_connections() as the comment in close_connection suggests, and
comment out the old code.
def close_connection(**kwargs):
#warnings.warn(
#"close_connection is superseded by close_old_connections.",
#PendingDeprecationWarning, stacklevel=2)
## Avoid circular imports
#from django.db import transaction
#for conn in connections:
## If an error happens here the connection will be left in broken
## state. Once a good db connection is again available, the
## connection state will be cleaned up.
#transaction.abort(conn)
#print(" from within close_connection method ")
#connections[conn].close()
close_old_connections()
I am not a Django expert, much less a Django/db expert. Could somebody
investigate whether something like this can be done and released in Django
1.6.8? I am especially puzzled by why the two autocommit values are
different. Should I do something else (in Django test
client/settings/elsewhere) to make the two autocommit values the same? If
this "fix" helps you guys, fine; we are interested in some proper fix
coming from Django directly rather than patching things up ourselves.
Thanks,
Arun
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group an
django fquery tutorial
Are you interested in using python 3.7 dataclasses to represent both django database models, views and get graphql interfaces for free? I wrote up a tutorial on how to use fquery with django: https://adsharma.github.io/django-fquery/ More about fquery: https://adsharma.github.io/fquery/ Earlier discussion: https://code.djangoproject.com/ticket/32759 Thank you for any comments or feedback. -Arun -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c9bab50f-23af-40a3-86ae-cc6ba7cafcf8n%40googlegroups.com.
VALUE not resetting on Foriegn Key Delete
Hi,
I have a Model Class which has the Below schema:
class Pvt_ip_pools(AtlasAuditModel, AtlasBaseHelper):
"""
Represents a private IP Address used for LB Model.
This inherits all the fields from IPAddress model(database table).
"""
# Each data center has its own IP address range
data_center = models.ForeignKey(DataCenter,
verbose_name="Data Center")
ip = models.GenericIPAddressField(verbose_name="PvtIP",
blank=False,
null=False,
unique=True)
prefix_length = models.PositiveSmallIntegerField(blank=False,
null=False,
unique=False)
gateway = models.GenericIPAddressField(blank=False,
null=False,
unique=False)
* server_interface =
models.ForeignKey('ServerInterface',
related_name='pvt_ip_pools',
blank=True,
null=True,
default=None,
on_delete=models.SET_NULL)*
ipv6 = models.BooleanField(default=0)
segment_id = models.IntegerField(default=0,
verbose_name="Segment_ID")
*ip_status =
models.ForeignKey('IPStatus',
default=None,
null=True, on_delete=models.CASCADE)*
class Meta:
verbose_name = "[LB]Private IP Address"
verbose_name_plural = "[LB]Private IP Addresses"
In this, When a ServerInterface is Deleted, which is a foriegn Key, the
Model here, sets the attribute to NULL.
But, each of these will have a Object "IP_STATUS" which will have a value
assigned ( FREE, USED ..)
*Now On Delete of the ServerInterface Object, How do i reset the Value of
"IP_STATUS" to FREE everytime Server_interface object is deleted?*
Another Problem observed is that When The ServerINterface Object is deleted
from ADMIN page, offcourse, it will not call the default delete.
Even in this case
*, how do i reset the value of IP_STATUS? when Object deleted from ADMIN
Page.*
Any Help is much appreciated.
*Cheers*
*Arun*
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/147aedbd-7dd2-4cef-bfda-7cd79e9b2e2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
