Django dynamic form creation
I am trying to create a splitwise <https://www.splitwise.com/> clone
application for my weekend project. I have arrived at a stage where I have
to create a new Bill. Please find below screenshot.
In this form I have three queries:
1. A dynamic form where a model with fields (amount, user) can be added
or removed dynamically. I am using modelformset_factory to perform this
operation. From the UI's perspective I am using javascript to add two
fields based onClick operation and similarly remove onClick, please check
code. My question is, is this correct approach from UI's perspective to
create dynamic fields using javascript or is there any other right way ?
2. I am passing users list from views.py to my bill.html template.
Again, is this a correct approach ? Or is there any other right way ?
3. After creating multiple split forms and clicking on create Bill. At
the view.py I am receiving only one split form rather than multiple ?? I am
thinking something is wrong because of might be above two approaches are
not correct !!! Need help over this.
[image: Screenshot 2020-03-19 at 1.31.33 PM.png]
This is the javascript I am using to create split model having two fields
(amount and user). Providing the existing users list from the users args I
passed from the views.py
bill.html
>
> var room = 1;
> function education_fields() {
> room++;
> var objTo = document.getElementById('education_fields')
> var divtest = document.createElement("div");
>divtest.setAttribute("class", "form-group removeclass"+room);
>var rdiv = 'removeclass'+room;
> divtest.innerHTML = '<div class="col-sm-5 nopadding"><div
> class="form-group"> <input type="text"
> class="form-control" id="amount" placeholder="Amount"></div></div><div
> class="col-sm-5 nopadding">
> <div class="form-group"> <select type="select" class="form-control">
> {% for user in users %}<option>{{user}}</option>{% endfor
> %}</select></div></div>
> <div class="col-sm-2 nopadding"><div class="form-group"><div
> class="input-group">
> <div class="input-group-btn"> <button class="btn btn-danger"
> type="button" onclick="remove_education_fields('+ room +');">
> <span class="glyphicon glyphicon-minus" aria-hidden="true"></span>
> </button></div></div></div></div><div class="clear"></div>';
> objTo.appendChild(divtest)
> }
>function remove_education_fields(rid) {
> $('.removeclass'+rid).remove();
>}
>
>
>
models.py
> class Bill(models.Model):
> bill_id = models.AutoField(primary_key=True, null=False)
> bill_name = models.CharField(max_length=100)
> total_amount = models.IntegerField()
>
> def __str__(self):
> return "%s-%s"%(str(self.bill_id), self.bill_name)
>
> class Split(models.Model):
> amount = models.IntegerField()
> split_user = models.ForeignKey(User, on_delete=models.CASCADE, null=True)
> bill = models.ForeignKey(Bill, on_delete=models.CASCADE, null=False,
> default='')
>
> def __str__(self):
> return "%s-%s" % (str(self.bill_id), self.amount)
>
>
forms.py
> class BillModelForm(forms.ModelForm):
> class Meta:
> model = Bill
> fields = ('bill_name', 'total_amount')
> labels = {
> 'bill_name': 'Enter the Expenditure',
> 'total_amount': 'Enter the total amount',
> }
>
> SplitFormSet = modelformset_factory(
> Split,
> fields=('amount','split_user'),
> extra=1,
> labels = {
> 'amount': 'Enter the split amount',
> 'split': "Share Friend",
> },
> widgets={
> 'amount': forms.TextInput(
> attrs={
> 'class': 'form-control',
> 'placeholder': 'Amount',
> 'id':'amount',
> }
> ),
> 'split_user': forms.Select(
> attrs={
> 'class': 'form-control',
> 'placeholder': '',
> },
> )
> }
> )
>
>
Thanks,
Rahul
--
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/CAN%2BO0S7vzzRRH%2Bh-gLGnp6av5y%3Dj0fXQCfK_a0zqSYP_tfs_iQ%40mail.gmail.com.
please help me i am trying to solve it from 5 days but still did not get the solution so please help me here is problem
https://github.com/rahul6612/flying-store/issues/1? -- 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/4edfde6b-c4db-4cb8-b0f5-fe87912bc89b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
New Release of IBM_DB_DJANGO (1.0.7)
IBM_DB_DJANGO-1.0.7
---
IBM_DB_DJANGO adaptor enables access to IBM databases from Django
applications http://www.djangoproject.com/.
The adaptor is developed and maintained by IBM.
What's New?
- Added support for Django-1.7, with backward compatibility
- Added Schema migration support for Django's schema migration
implementation
- Added support to get SmallIntegerField field reverse mapping
- Added support to get all the constraints from given table
- Added Django's power operator('^') support in query
GIT access to the source
---
http://code.google.com/p/ibm-db/source/browse/#git/IBM_DB/ibm_db_django/
Installation
$ easy_install ibm_db_django
Feedback/Suggestions/Issues
You can provide us feedback/suggestions, or report a bug/defect, or ask for
help by using any of the following channels:
1. Mailing us at open...@us.ibm.com
2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list.
3. By opening new discussion at http://groups.google.co.in/group/ibm_db.
For prerequisites, installation steps and help details, visit -
http://code.google.com/p/ibm-db/wiki/ibm_db_django_README
Try this out and let us know you valuable feedback.
Cheers,
Rahul Priyadarshi
Download Express-C for free, go to:
---
http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01_TACT=ACDB2011
--
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/7aad7b79-4725-4f8a-9b8a-03092bbaa889%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: 3rd-party database backends: Do you need a "can_introspect_null" feature flag?
DB2 backend can introspect the nullability correctly, but it can't introspect BooleanField. It introspect Boolean field as SmallIntegerField but in the test case if can_introspect_boolean_field=False then it checks only for IntegerField. By including introspect_boolean_field_as_smallInteger and introspect_boolean_field_as_Integer feature flag can eliminate this problem. -- You received this message because you are subscribed to the Google Groups "Django developers" 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/fb10be1d-682f-4a7b-b07a-2ab27ccca72f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Database-dependant tests and third-party backends
DECIMAL datatype of DB2 also doesn't supports max_digits 38 and decimal_places = 30. In DB2 precision range defined between 1 to 31 and In firebird range is 1 to 18(ref http://www.promotic.eu/en/pmdoc/Subsystems/Db/FireBird/DataTypes.htm) It would be good if max_digits and decimal_places can be changed in the range which is valid for Django's 3rd party backends also. -- You received this message because you are subscribed to the Google Groups "Django developers" 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/288e325a-bc1b-4818-8684-0069a06f7751%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Database-dependant tests and third-party backends
I have created a ticket #22653 ( https://code.djangoproject.com/ticket/22653 ), for the issue I have mentioned. -- You received this message because you are subscribed to the Google Groups "Django developers" 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/27af1382-aaca-4100-b8ad-fb8060f5cca9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Database-dependant tests and third-party backends
Hi, I am maintaining DB2 backend and facing same problem, there is need to change as much as we can change vendor depended check to features depended test. some of test cases written with keeping some features of backend in mind but they didn't have putted the feature check there. Following test cases requires to check can_defer_constraint_checks since these test cases wants to defer constraints check but database like DB2 doesn't allow to defer within a transaction also. i) test cases under admin_views.tests.AdminViewDeletedObjectsTest test class ii) test cases under serializers_regress.tests.SerializerTests test class Following test cases requires supports_forward_references flag check i) serializers.SerializersTransactionTestBase.test_forward_refs ii) fixtures_regress.TestFixtures.test_loaddata_works_when_fixture_has_forward_refs iii) fixtures_regress.TestFixtures.test_loaddata_forward_refs_split_fixtures Thanks, Rahul -- You received this message because you are subscribed to the Google Groups "Django developers" 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/6b26dffd-d666-468d-b83b-b30f4c93eb38%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
New Release of IBM_DB_DJANGO (1.0.6)
IBM_DB_DJANGO-1.0.6 --- IBM_DB_DJANGO adaptor enables access to IBM databases from Django applications http://www.djangoproject.com/. The adaptor is developed and maintained by IBM. What's New? - Added support for Django-1.6, with backward compatibility - Added support for Django's persistence connection - Added cache culling sql for IBM databases to retrieves the first cache key greater than the n smallest - Added time zone-aware day, month and day-of-week lookups - Added time zone-aware truncated timestamps on the basis of lookup type - Enhanced Regex lookup implementation to add non string field regex lookup - Added support for sequence reset by sequence name - Added support to get list of keys columns of a given table - Changed the implementation to remove multi field indexes from index list - Added new setting property FETCH_DISTINCT_ON_TEXT, if one set it to False then 'DISTINCT' will get removed silently from select query when it contains LOB values in projection list. GIT access to the source --- http://code.google.com/p/ibm-db/source/browse/#git/IBM_DB/ibm_db_django/ Installation $ easy_install ibm_db_django Feedback/Suggestions/Issues You can provide us feedback/suggestions, or report a bug/defect, or ask for help by using any of the following channels: 1. Mailing us at open...@us.ibm.com 2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list. 3. By opening new discussion at http://groups.google.co.in/group/ibm_db. For prerequisites, installation steps and help details, visit - http://code.google.com/p/ibm-db/wiki/ibm_db_django_README Try this out and let us know you valuable feedback. Cheers, Rahul Priyadarshi Download Express-C for free, go to: --- http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01_TACT=ACDB2011 -- You received this message because you are subscribed to the Google Groups "Django developers" 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/d4f82881-1dd3-42eb-a99a-4a344390d3a6%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
New Release of IBM_DB_DJANGO (1.0.5)
IBM_DB_DJANGO-1.0.5 --- IBM_DB_DJANGO adaptor enables access to IBM databases from Django applications http://www.djangoproject.com/. The adaptor is developed and maintained by IBM. What's New? - Added support for Django-1.5, with backward compatibilty - Added support for REGEX lookup - Added support for Python-3.x GIT access to the source --- http://code.google.com/p/ibm-db/source/browse/#git/IBM_DB/ibm_db_django/ Installation $ easy_install ibm_db_django Feedback/Suggestions/Issues You can provide us feedback/suggestions, or report a bug/defect, or ask for help by using any of the following channels: 1. Mailing us at open...@us.ibm.com 2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list. 3. By opening new discussion at http://groups.google.co.in/group/ibm_db. For prerequisites, installation steps and help details, visit - http://code.google.com/p/ibm-db/wiki/ibm_db_django_README Try this out and let us know you valuable feedback. Cheers, Rahul Priyadarshi Download Express-C for free, go to: --- http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01_TACT=ACDB2011 -- You received this message because you are subscribed to the Google Groups "Django developers" 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django sanctioned extensions
Hi, I maintain the IBM DB2 Django backend (ibm_db_django) project(http://code.google.com/p/ibm-db/). We have been maintaining this extension since Django-1.0 and have always kept it up-to-date. The http://code.google.com/p/ibm-db/ project also provides a Python DBI compliant driver, based on which the Django back-end is built. (For the record, in the past some of our customers have requested for Django to include the DB2 backend in core, which didnt happen). I really like Russell's idea to introduce officially recognized extensions. If that is the outcome of this thread, I would like to add the DB2 extension as officially recognized and will help in setting infrastructure for this if I can. I would prefer the automated test environment for recognized extensions so that any core Django commit will get expose if it cause any problem in some specific backend, In this way committer can raise a ticket against specific backend if any changes required in that. Thanks, Rahul Priyadarshi On Saturday, March 9, 2013 10:19:30 AM UTC+5:30, Russell Keith-Magee wrote: > > > On Fri, Mar 8, 2013 at 11:23 AM, <ry...@ryanhiebert.com >wrote: > >> from thread "Moving database backends out of the core" >> >> On Mar 7, 2013, at 5:13 PM, Russell Keith-Magee >> <rus...@keith-magee.com> >> wrote: >> >> > There is, however, a possible middle ground, following the example set >> by Flask: we introduce to Django a list of "officially recognised" >> extensions. These extensions are still maintained as external projects, but >> the core team promise to include these projects as part of the testing >> regimen for a release. If the MSSQL backend were recognised like this, we >> would run the full Django test suite against the MSSQL backend, and if that >> testing revealed a bug in the test suite which was identified as being due >> to a change in Django's codebase, that bug would be a release blocker (Bugs >> in the backend itself would still be the backend's responsibility, and not >> release blocking on Django) >> > >> > Looking outside database backends, this could also apply to >> high-profile projects like haystack, django-registration, and so on. This >> would also serve to highlight projects in our community that are 'defacto >> standards', or good examples of reusability, without needing to expand the >> core team or the size of contrib, and show that the core project is >> explicitly interested in the broader ecosystem. >> >> I think this is a great idea. The backend testing makes sense to me (run >> Django's tests). How does testing sanctioned apps work, though? You run >> _their_ tests, and if they are caused by bugs in Django then they are >> release blockers? >> > > Caveat: I haven't given a huge amount of thought to this beyond the basic > idea, so this is all my initial thoughts. > > I can see three options: > > 1) We run the tests. This requires that we come up with a standard for > describing how test environments work. This could be as simple as requiring > that python setup.py test works, and produces output in a known format. > Requiring the use of tox, or Jenkins/Travis configs would be another option. > > 2) We leave running the tests up to individual projects, but require them > to expose test results in a standard way. No idea how this would be > specified, other than possibly a HTTP API endpoint. > > 3) We make it completely manual. This is something that only needs to > happen around release time, so as long as it's relatively easy to run the > full suite of tests manually, it may be possible to manually maintain a > database of "working/not working". > > Option 3 might be the easiest way to get going - after all, you can always > add automation infrastructure later. > > I really like the idea, and would like to help if I can. I imagine the leg >> work will be mostly in setting up the testing infrastructure, although the >> difficult part will be setting guidelines for and choosing apps that should >> be in this group. > > > Agreed that this is more a policy/procedures issue than a technical issue. > I'm not sure what the best approach is for this - I'm open to suggestions. > > As for how to get this ball rolling -- well, I suppose there's two tasks > that could be addressed immediately: > > * A list of candidate packages -- even if it's not the final approved > list, we need somewhere to start > > * A first cut at a site to host this information. > > My local Django Users Group (in Perth, Western Australia) had some > interesting discussions about this sort of packaging project at our
New Release of IBM_DB_DJANGO (1.0.4)
IBM_DB_DJANGO-1.0.4 --- IBM_DB_DJANGO adaptor enables access to IBM databases from Django applications http://www.djangoproject.com/. The adaptor is developed and maintained by IBM. What's New? - Added support for Django-1.4 - Backward compatibilty - Same codebase works with older supported version of Django - Added support to enable Django's USE_TZ feature - Added support for Django's bulk_create - Added support for 'SELECT FOR UPDATE' - Added module version string __version__ SVN access to the source --- http://code.google.com/p/ibm-db/source/browse/trunk/IBM_DB/ibm_db_django/ Installation $ easy_install ibm_db_django Feedback/Suggestions/Issues You can provide us feedback/suggestions, or report a bug/defect, or ask for help by using any of the following channels: 1. Mailing us at open...@us.ibm.com 2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list. 3. By opening new discussion at http://groups.google.co.in/group/ibm_db. For prerequisites, installation steps and help details, visit - http://code.google.com/p/ibm-db/wiki/ibm_db_django_README Try this out and let us know you valuable feedback. Have fun. Cheers, Rahul Priyadarshi Download Express-C for free, go to: --- - http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01_TACT=ACDB2011 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ibm_db_django-1.0.2 IBM Dataservers backend support for Django 1.3 Released
IBM_DB_DJANGO-1.0.2 --- IBM_DB_DJANGO adaptor enables access to IBM databases from Django applications http://www.djangoproject.com/. The adaptor is developed and maintained by IBM. What's New? - Added support for Django-1.3 - Backward compatibility - Same codebase works with Django 1.0.x, 1.1.x, 1.2.x and 1.3.x - Fixed Unique column constraint having more than one NULL value - Fixed Unique columns together having more than one NULL value - Added date interval functionality - Fixed Boolean data type return for BooleanField/NullBooleanField SVN access to the source --- http://code.google.com/p/ibm-db/source/browse/trunk/IBM_DB/ibm_db_django/ Installation $ easy_install ibm_db_django Feedback/Suggestions/Issues You can provide us feedback/suggestions, or report a bug/defect, or ask for help by using any of the following channels: 1. Mailing us at open...@us.ibm.com 2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list. 3. By opening new discussion at http://groups.google.co.in/group/ibm_db. For prerequisites, installation steps and help details, visit - http://code.google.com/p/ibm-db/wiki/ibm_db_django_README Try this out and let us know you valuable feedback. Have fun. Cheers, Rahul Priyadarshi Download Express-C for free: --- http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01_TACT=ACDB2011 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Problem due to contenttype cache
Hi carl, I have file a ticket for this. For details please find it on http://code.djangoproject.com/ticket/15568 Thanks, Rahul Priyadarshi On Mar 5, 9:27 am, Carl Meyer <carl.j.me...@gmail.com> wrote: > On Mar 4, 5:55 am, Rahul <rahul.priyadar...@in.ibm.com> wrote: > > > > > When i ran test cases of multiple_databases model of regressiontests > > then "test_generic_key_deletion" test case gave Error at the point > > where it was trying to create Review object using "other" db, > > but when i ran "test_generic_key_deletion" test case only then it > > passed perfectly. > > > When i narrowed the problem and run this test case with > > "test_generic_key_cross_database_protection" then even it gives Error > > at same line. > > > In my investigation i found that in > > "test_generic_key_cross_database_protection" test case, one Reiview > > object is getting created and because there exist FK relationship with > > ContentType, content type record for this is getting populated in DB > > and content type lookup are cached. At the end of this test case, > > content type record gets cleared by rollback, but content type lookup > > still remain in cache, so that when inside "test_generic_key_deletion" > > it tries to create Review object it gets content type from the cache > > and does not have to go to DB. Next when it tries to populate review > > table, Integrity error is raised as it has not made entry to content > > type table. > > > I also tested it with InnoDB and getting same error here as well. > > > Could you please let me know if you wants to let it gives error for > > this test case for InnoDB or I am running this wrong way. > > Any failed test on a supported backend (which includes InnoDB) is a > bug. Please file a ticket, including this information and the full > settings with which you're running the tests. Thanks! > > Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Problem due to contenttype cache
When i ran test cases of multiple_databases model of regressiontests then "test_generic_key_deletion" test case gave Error at the point where it was trying to create Review object using "other" db, but when i ran "test_generic_key_deletion" test case only then it passed perfectly. When i narrowed the problem and run this test case with "test_generic_key_cross_database_protection" then even it gives Error at same line. In my investigation i found that in "test_generic_key_cross_database_protection" test case, one Reiview object is getting created and because there exist FK relationship with ContentType, content type record for this is getting populated in DB and content type lookup are cached. At the end of this test case, content type record gets cleared by rollback, but content type lookup still remain in cache, so that when inside "test_generic_key_deletion" it tries to create Review object it gets content type from the cache and does not have to go to DB. Next when it tries to populate review table, Integrity error is raised as it has not made entry to content type table. I also tested it with InnoDB and getting same error here as well. Could you please let me know if you wants to let it gives error for this test case for InnoDB or I am running this wrong way. Thanks, Rahul Priyadarshi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Delete cascade up for Inherited models
Thanks carl for updating me about this fix. I was using 1.3-beta-1 version of django. When i run it with latest trunk version it works fine. Thanks, Rahul Priyadarshi On Feb 24, 9:16 am, Carl Meyer <carl.j.me...@gmail.com> wrote: > Hi Rahul, > > On Feb 21, 12:56 am, Rahul <rahul.priyadar...@in.ibm.com> wrote: > > > When i ran the test cases ( "modeltests/delete/ > > test_inheritance_cascade_up" ) which were doing cascade up for > > inherited models, it failed for DB2 cause of the fact that DB2 doesn't > > support initial deferred constraint checks like behavior, hence it is > > must to execute delete statement from child to parent, however when I > > traced the sql execution for "modeltests/delete/ > > test_inheritance_cascade_up" test case, what I find is Django tried to > > execute delete sql from parent to child. I already had the flag > > "can_defer_constraint_checks" set to false inside DatabaseFeatures. > > What version of Django are you developing against? This sounds very > much like #15118 [1], which is present in the 1.3 beta but was fixed > in trunk over a month ago by r15246 [2]. > > Carl > > [1]http://code.djangoproject.com/ticket/15118 > [2]http://code.djangoproject.com/changeset/15246 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Delete cascade up for Inherited models
When i ran the test cases ( "modeltests/delete/ test_inheritance_cascade_up" ) which were doing cascade up for inherited models, it failed for DB2 cause of the fact that DB2 doesn't support initial deferred constraint checks like behavior, hence it is must to execute delete statement from child to parent, however when I traced the sql execution for "modeltests/delete/ test_inheritance_cascade_up" test case, what I find is Django tried to execute delete sql from parent to child. I already had the flag "can_defer_constraint_checks" set to false inside DatabaseFeatures. Wondering if there a hook exists through which i can change the parent to child execution of sql to child to parent through our DB2 Django adaptor. Any help would be appreciated Thanks, Rahul Priyadarshi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Question on ForeignKey (on_delete=DO_NOTHING)
Thanks carl for you reply.
we were setting supports_transaction flag in settings but now i get to
know from Russ Megee's post(http://groups.google.com/group/django-
developers/browse_thread/thread/5c1c3cdfd1e4728e/) that this flag has
been moved to DatabaseFeatures.
When i set this flag in DatabaseFeatures then for full test suit also
both test cases of "contenttypes" app works fine.
But i am not able to figure out why this test case was failing when we
were not sets supports_transaction flag.
Thanks,
Rahul Priyadarshi
On Feb 2, 7:18 pm, Carl Meyer <carl.j.me...@gmail.com> wrote:
> Hi Rahul,
>
> On Feb 2, 4:03 am, Rahul <rahul.priyadar...@in.ibm.com> wrote:
>
> > When i run the entire inbuilt test suit of django, first test case it
> > hits is of contenttypes app of contrib apps and first test
> > case(intest_lookup_cache) works fine. But when it hits the 2nd test
> > case (test_shortcut_view) it first flushes out all tables and then
> > tries to insert data in "AUTH_PERMISSION" table. But as there is a
> > foreign key relationship between this and "DJANGO_CONTENT_TYPE" table,
> > and there is no data in parent table ("DJANGO_CONTENT_TYPE") becuase
> > of the flush it fails with Integrity Error.
>
> First question - my impression was that DB2 supports transactions? The
> contenttypes test you're referring to uses a regular TestCase (not a
> TransactionTestCase), which means that it should not be flushing the
> database between tests, it should simply perform a rollback to return
> the database to its prior state after each test. Does your backend not
> make use of DB2 transaction support? Does it not set the
> "supports_transactions" backend feature to True?
>
> Flushing the database after every test will make running the test
> suite very slow, compared to using transactions.
>
> > But when i run testsuite for "contenttypes" app only, then both test
> > case of this app works fine.
> > When i traced the squence of sql executed for 2nd test case of this
> > app, I found that in this case there is a insert statement that gets
> > executed for "DJANGO_CONTENT_TYPE" before for the "AUTH_PERMISSION".
>
> The "flush" command sends the post_syncdb signal (see core/management/
> commands/flush.py). The contenttypes app listens for the post_syncdb
> signal to repopulate the contenttypes table (see contrib/contenttypes/
> management.py). I don't know why it seems to be failing to do this for
> you when you run the full suite, but I know it works when the test
> suite is run for other backends (I just ran the full suite for MySQL
> ISAM, which also uses flush because it doesn't support transactions -
> not the whole way through because it takes forever, but it completed
> the contenttypes tests just fine before I interrupted it).
>
> Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Question on ForeignKey (on_delete=DO_NOTHING)
When i run the entire inbuilt test suit of django, first test case it
hits is of contenttypes app of contrib apps and first test
case(intest_lookup_cache) works fine. But when it hits the 2nd test
case (test_shortcut_view) it first flushes out all tables and then
tries to insert data in "AUTH_PERMISSION" table. But as there is a
foreign key relationship between this and "DJANGO_CONTENT_TYPE" table,
and there is no data in parent table ("DJANGO_CONTENT_TYPE") becuase
of the flush it fails with Integrity Error.
But when i run testsuite for "contenttypes" app only, then both test
case of this app works fine.
When i traced the squence of sql executed for 2nd test case of this
app, I found that in this case there is a insert statement that gets
executed for "DJANGO_CONTENT_TYPE" before for the "AUTH_PERMISSION".
I am Wondering why this insert does not get executed when i run the
complete test suite, but does when i run the indiviual test suite
standalone. Any tips on above behavior or where should i look to
resolve this would be appreciated.
Thanks,
Rahul Priyadarshi
On Jan 31, 4:53 pm, Rahul <rahul.priyadar...@in.ibm.com> wrote:
> Carl,
> you are right. I didn't mention the actual problem i was facing...
> Prior to 1.3 the way we implemented 'sqlflush' was to simply turn on
> 'cascade_delete' in DB2 and then return 'delete from TABLENAME' for
> every table passed in. Without the delete_cascade, this required the
> delete's to be sorted in right order (and then what about circular
> references). But in 1.3 with the new DO_Nothing this wouldn't work.
> And i was seeing many errors in 1.3 due to PKEY/FKey issues that i
> thought were related to follow-on test cases expecting some rows to be
> there, but no more there (since delete & cascade happened). Knowing
> this as 1 issue, i just wanted to skip it and run the remainder of
> tests to get a feeling how many other things i need to deal with for
> 1.3...
>
> BTW i have come up with a different workaround for sqlflush and it
> works, but i still see lots of errors related to pkey/fkey
> dependencies out of sync :-(. Digging into that and if i am stuck will
> post some queries again
>
> thanks
> Rahul Priyadarshi
>
> On Jan 25, 9:15 am, Carl Meyer <carl.j.me...@gmail.com> wrote:
>
> > On Jan 24, 3:51 am,Rahul<rahul.priyadar...@in.ibm.com> wrote:
>
> > > Can you let me know how i can specify that this test case should not
> > > be run, when i run the inbuilt unit test-cases. Currently i just run
> > > them like this 'python runtests.py --setting=settings'
>
> > You should not avoid running test_do_nothing. It is written such that
> > it can pass without error on backends that support referential
> > integrity, and the comment mentions a possible IntegrityError as a
> > reason for how it is written, but nowhere in the test is an
> > expectation of IntegrityError tested. In other words, the test should
> > (and does) pass equally well on backends that do or do not support
> > referential integrity, and it should pass for your backend as well.
>
> > The only place in the deletion tests where IntegrityError is
> > explicitly tested for is in test_protect, as the PROTECT
> > IntegrityError is raised by Django's own deletion code, not the
> > backend.
>
> > Carl
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Question on ForeignKey (on_delete=DO_NOTHING)
Carl, you are right. I didn't mention the actual problem i was facing... Prior to 1.3 the way we implemented 'sqlflush' was to simply turn on 'cascade_delete' in DB2 and then return 'delete from TABLENAME' for every table passed in. Without the delete_cascade, this required the delete's to be sorted in right order (and then what about circular references). But in 1.3 with the new DO_Nothing this wouldn't work. And i was seeing many errors in 1.3 due to PKEY/FKey issues that i thought were related to follow-on test cases expecting some rows to be there, but no more there (since delete & cascade happened). Knowing this as 1 issue, i just wanted to skip it and run the remainder of tests to get a feeling how many other things i need to deal with for 1.3... BTW i have come up with a different workaround for sqlflush and it works, but i still see lots of errors related to pkey/fkey dependencies out of sync :-(. Digging into that and if i am stuck will post some queries again thanks Rahul Priyadarshi On Jan 25, 9:15 am, Carl Meyer <carl.j.me...@gmail.com> wrote: > On Jan 24, 3:51 am,Rahul<rahul.priyadar...@in.ibm.com> wrote: > > > Can you let me know how i can specify that this test case should not > > be run, when i run the inbuilt unit test-cases. Currently i just run > > them like this 'python runtests.py --setting=settings' > > You should not avoid running test_do_nothing. It is written such that > it can pass without error on backends that support referential > integrity, and the comment mentions a possible IntegrityError as a > reason for how it is written, but nowhere in the test is an > expectation of IntegrityError tested. In other words, the test should > (and does) pass equally well on backends that do or do not support > referential integrity, and it should pass for your backend as well. > > The only place in the deletion tests where IntegrityError is > explicitly tested for is in test_protect, as the PROTECT > IntegrityError is raised by Django's own deletion code, not the > backend. > > Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Question on ForeignKey (on_delete=DO_NOTHING)
Can you let me know how i can specify that this test case should not be run, when i run the inbuilt unit test-cases. Currently i just run them like this 'python runtests.py --setting=settings' thanks Mario -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Question on ForeignKey (on_delete=DO_NOTHING)
Hi, I am working on upgrading DB2 Django adaptor for 1.3. I had a small question on the above. As per the docs of 'DO_NOTHING', you mention 'IF' your DB backend enforces referential integrity, this will cause an IntegrityError. http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.on_delete Thus i assume that Django does not mandate that a database backend support referential integrity. However in your test suite, you have test cases that are expecting 'IntegrityError' in the case of DO_NOTHING. Can you shed some light on this. regards, Rahul Priyadarshi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
New Release of ibm_db_django(1.0.1)
IBM_DB_DJANGO-1.0.1 --- IBM_DB_DJANGO adaptor enables access to IBM databases from Django applications http://www.djangoproject.com/. The adaptor is developed and maintained by IBM. What's New? - Fixed LIMIT constraint in select statement with column name alias - Fixed Unique column constraint with one NULL value - Fixed Unique columns together with one null value - Added Standard deviation, Variance function support (for population standard deviation and variance) - Added MOD, BITAND and BITOR function support SVN access to the source --- http://code.google.com/p/ibm-db/source/browse/trunk/IBM_DB/ibm_db_django/ Installation $ easy_install ibm_db_django Feedback/Suggestions/Issues You can provide us feedback/suggestions, or report a bug/defect, or ask for help by using any of the following channels: 1. Mailing us at open...@us.ibm.com 2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list. 3. By opening new discussion at http://groups.google.co.in/group/ibm_db. For prerequisites, installation steps and help details, visit - http://code.google.com/p/ibm-db/wiki/ibm_db_django_README Try this out and let us know you valuable feedback. Have fun. Cheers, Rahul Priyadarshi Download Express-C for free, go to: --- - http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01_TACT=ACDB2011 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
New Release of ibm_db_django(1.0) is out of beta
IBM_DB_DJANGO-1.0 --- IBM_DB_DJANGO adaptor enables access to IBM databases from Django applications http://www.djangoproject.com/. The adaptor is developed and maintained by IBM. What's New? - Added IBM Dataservers backend support for Django 1.0.x and 1.1.x application Framework using Jython language SVN access to the source --- http://code.google.com/p/ibm-db/source/browse/trunk/IBM_DB/ibm_db_django Installation $ easy_install ibm_db_django Feedback/Suggestions/Issues You can provide us feedback/suggestions, or report a bug/defect, or ask for help by using any of the following channels: 1. Mailing us at open...@us.ibm.com 2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list. 3. By opening new discussion at http://groups.google.co.in/group/ibm_db. For prerequisites, installation steps and help details, visit - http://code.google.com/p/ibm-db/wiki/ibm_db_django_README Try this out and let us know you valuable feedback. Have fun. Thanks, Rahul Priyadarshi Get Started with DB2 Express-C 9.7.1 DB2 9.7 is now available. Download Express-C for free, go to: http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01_TACT=ACDB2011 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ibm_db_django now supports Django-1.2
IBM_DB_DJANGO-0.2.0 --- IBM_DB_DJANGO adaptor enables access to IBM databases from Django applications http://www.djangoproject.com/. The adaptor is developed and maintained by IBM. What's New? - Added support for Django-1.2 - Backward compatibility - Same codebase works with Django 1.0.x, 1.1.x and 1.2 - Exact look-up for LOB fields upto 4k Chars of data - added tablespace_sql method in operations.DatabaseOperations SVN access to the source --- http://code.google.com/p/ibm-db/source/browse/trunk/IBM_DB/ibm_db_django/ Installation $ easy_install ibm_db_django Feedback/Suggestions/Issues You can provide us feedback/suggestions, or report a bug/defect, or ask for help by using any of the following channels: 1. Mailing us at open...@us.ibm.com 2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list. 3. By opening new discussion at http://groups.google.co.in/group/ibm_db. For prerequisites, installation steps and help details, visit - http://code.google.com/p/ibm-db/wiki/ibm_db_django_README Try this out and let us know you valuable feedback. Thanks, Rahul Priyadarshi Get Started with DB2 Express-C 9.7.1 DB2 9.7 is now available. Download Express-C for free, go to: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=swg-db2expressc_CMP=ECDDWW01_TACT=ACDB206 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Problem with history view in admin page
Hi All, There is a problem reported for history view in admin page. For history view there is a sql query generated, which trying to do exact look-up on OBJECT_ID column (LogEntry model, DJANGO_ADMIN_LOG table). "TextField" is responsible for handling large text and in DB2 "TextField" is mapped to CLOB. DB2 doesn't support exact look-up with CLOB datatype. When I checked the values for this OBJECT_ID column in the database, it only contains integer (1, 2, 3, etc.). Now the question arises: Why "OBJECT_ID" defined as "TextField" type? In most of the cases "XXX_ID" field is expected to be INTEGER. Is there any specific reason why "OBJECT_ID" defined as "TextField" in LogEntry model in "django\contrib\admin\models.py". The original post of this problem is available on http://groups.google.com/group/ibm_db/browse_thread/thread/368e5739eb358e20 Regards, Rahul Priyadarshi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
