Re: Discussion on Ticket #16304
Thank you for your inputs. I have updated the patch. Will keep in mind to think a bit about the overall design before jumping headfirst and writing a patch. There is an existing ticket with patch to support HTML5 input types (#16630). This is also addressed by the template-based-widgets patch in #15667. I think the latter is the best direction, but it is blocked by slowness of the template engine. Thanks for the links. Will see if I can contribute. Patches without tests won't be committed. There are many existing examples of tests that test form rendering and HTML output; for instance, most of the tests in regressiontests/forms/. I will keep that in mind. The updated patch has tests. P.S. carljm: Can you please have a look at https://code.djangoproject.com/ticket/14394 Is the patch acceptable? (Disclaimer: I did not write it.) If not, how can I contribute? On Mon, Feb 13, 2012 at 5:37 AM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > On 02/11/2012 10:13 AM, j4nu5 wrote: > > I have written a patch for ticket #16304 (https:// > > code.djangoproject.com/ticket/16304). > > Thanks for the patch. > > > The ticket adds support for the HTML5 input placeholder attribute > > (WHAT Working Group placeholder description - > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute > ), > > in Forms as well as ModelForms. > > I agree with the previous commenter that HTML widget attributes do not > belong in model field definitions. Making it possible to achieve > arbitrary modifications to ModelForm output HTML without ever overriding > a widget in the ModelForm is a bad design goal; there's a reason the > ModelForm (and widgets) exist as an intermediary layer. > > > I was wondering if a larger undertaking can be taken to make Django > > HTML5 aware. Options may include support for new input types like tel, > > email etc. which currently are rendered simply as text and ModelForms/ > > Forms have to manually override widgets to achieve desired results. > > There is an existing ticket with patch to support HTML5 input types > (#16630). This is also addressed by the template-based-widgets patch in > #15667. I think the latter is the best direction, but it is blocked by > slowness of the template engine. > > > P.S. The submitted patch lacks tests. I could not figure out how to > > write tests for the UI. If that is acceptable, can core devs please > > accept the patch? > > Patches without tests won't be committed. There are many existing > examples of tests that test form rendering and HTML output; for > instance, most of the tests in regressiontests/forms/. > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk84VFsACgkQ8W4rlRKtE2fqbgCfZF+38wR0kbsdLnQ2oM5JBfxn > E0UAoOlnRgDVRXmuEaVPU2WsOe3C74Jh > =yR2q > -END PGP SIGNATURE- > > -- > 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. > > -- 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.
Django participation in Google Summer of Code 2012
Are there plans for Django participating in this year's Google Summer of Code. The organization application deadline is on 9th March. I would love to participate as a student. Thanks -- Kushagra SInha -- 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: Django participation in Google Summer of Code 2012
Thanks a lot for the reply. On Wed, Mar 7, 2012 at 5:02 AM, Russell Keith-Magee wrote: > > On 07/03/2012, at 5:35 AM, Kushagra Sinha wrote: > > > Are there plans for Django participating in this year's Google Summer of > Code. The organization application deadline is on 9th March. I would love > to participate as a student. > > > > Yes, we are planning to apply as an organization. > > If you're interested in doing a Django-based project, it's never too early > to start working on your proposal; historically, the applicants that have > been the most successful have started on their proposal (and their > projects) long before the "official" application period. Obviously, we > haven't got our 2012 SOC page up yet, but last year's page [1] will give > you a few ideas -- especially if you focus on projects that haven't been > completed, or were started on last year but still need some work to bring > them to completion. > > [1] https://code.djangoproject.com/wiki/SummerOfCode2011 > > Yours, > Russ Magee %-) > > -- > 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. > > -- Kushagra SInha B. Tech. Part III (Pre-final year) Indian Institute of Technology Varanasi Contact: +91 9415 125 215 -- 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.
[GSoC 2012] Schema Alteration API proposal
.test.simple
and django.contrib.gis.db.backends) will be left as is.
Therefore much of the code for our new migrations API will come from South.
For models:
class Author(models.Model):
name = models.CharField(max_length=100)
class Book(models.Model):
title = models.CharField(max_length=100)
author = models.ManyToManyField('Author')
the migrations file created under user app / migrations will look like:
class Migration(SchemaMigration):
def forwards(self, orm):
# Adding model 'Book'
db.create_table('myapp_book', (
('id', self.gf
('django.db.models.fields.AutoField')(primary_key=True)),
('title', self.gf
('django.db.models.fields.CharField')(max_length=100)),
))
db.send_create_signal('myapp', ['Book'])
# Adding M2M table for field author on 'Book'
db.create_table('myapp_book_author', (
('id', models.AutoField(verbose_name='ID', primary_key=True,
auto_created=True)),
('book', models.ForeignKey(orm['myapp.book'], null=False)),
('author', models.ForeignKey(orm['myapp.author'], null=False))
))
db.create_unique('myapp_book_author', ['book_id', 'author_id'])
# Adding model 'Author'
db.create_table('myapp_author', (
('id', self.gf
('django.db.models.fields.AutoField')(primary_key=True)),
('name', self.gf
('django.db.models.fields.CharField')(max_length=100)),
))
db.send_create_signal('myapp', ['Author'])
def backwards(self, orm):
# Deleting model 'Book'
db.delete_table('myapp_book')
# Removing M2M table for field author on 'Book'
db.delete_table('myapp_book_author')
# Deleting model 'Author'
db.delete_table('myapp_author')
models = {
'myapp.author': {
'Meta': {'object_name': 'Author'},
'id': ('django.db.models.fields.AutoField', [], {'primary_key':
'True'}),
'name': ('django.db.models.fields.CharField', [],
{'max_length': '100'})
},
'myapp.book': {
'Meta': {'object_name': 'Book'},
'author': ('django.db.models.fields.related.ManyToManyField',
[], {'to': "orm['myapp.Author']", 'symmetrical': 'False'}),
'id': ('django.db.models.fields.AutoField', [], {'primary_key':
'True'}),
'title': ('django.db.models.fields.CharField', [],
{'max_length': '100'})
}
}
complete_apps = ['myapp']
when the initial (blank) migration at app creation time is:
class Migration(SchemaMigration):
def forwards(self, orm):
pass
def backwards(self, orm):
pass
models = {}
complete_apps = ['myapp']
The above code snippets have been generated by South. Thus we already have
functionality for create_table, create_unique, delete_table etc. and the
inspection routines which have to be integrated into Django's codebase
(at django.db.migrations perhaps?)
Schedule and Goal
--
Week 1: Discussion on API design and overriding django-admin startapp
Week 2-3 : Developing the base migration API
Week 4: Developing migration extensions and overrides for PostgreSQL
Week 5: Developing migration extensions and overrides for MySQL
Week 6: Developing migration extensions and overrides for SQLite
Week 7: Developing the inspection tools
Week 8: Developing the ORM versioning tools and glue code
Week 9-10 : Writing tests/documentaion
Week 11-12: Buffer weeks for the unexpected, Oracle DB? and
djago.contrib.gis.backends?
Note: Work on Oracle and GIS may not be possible as part of GSoC
I will personally consider my project to be successful if I have created and
tested at least the base API + PostgreSQL extension and inspection + version
tools.
About me and my inspiration for the project
--
I am Kushagra Sinha, a pre-final year student at Institute of Technology
(about to be converted to an Indian Institute of Technology),
Banaras Hindu University, Varanasi, India.
I can be reached at:
Gmail: sinha.kushagra
Alternative email: kush [at] j4nu5.com
IRC: Nick j4nu5 on #django-dev and #django
Twitter: @j4nu5
github: j4n
Re: Schema Alteration API proposal
this in the GSoC is just too much, but trying to do a little part > (preferrably the _hardest_ part) is an important verification that the > API is correct. > > My opinion is that in the long term Django should aim for better > support of custom model fields, and having good support for these > fields in schema migrations is one important part of that. Geodjango > is an interesting example of hard to do custom model fields > > - Anssi > > -- > 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. > > -- Kushagra SInha B. Tech. Part III (Pre-final year) Indian Institute of Technology Varanasi Contact: +91 9415 125 215 -- 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: Schema Alteration API proposal
One more thing: The current creation API in django has methods like "sql_create_model" which basically return sql and it is the caller's responsibility to either call cursor.execute on it (syncdb) or output the sql itself (sql). South's (and xtrqt's) design is to have functions like "create_table" which execute the sql themselves. Makes little difference to commands like syncdb when they will be rewritten but commands like sql will have to so something like start_transaction, get_sql, rollback_transaction which is kinda hackish according to me. What should be the design of the new migrations api? Any thoughts on this? On Tue, Mar 20, 2012 at 3:47 AM, Andrew Godwin wrote: > On 19/03/12 20:33, Kushagra Sinha wrote: > >> Andrew's thread[1] also mentions - "backends will always be able to >> generate SQL for operations, but it won't necessarily be runnable >> (things like index names can only be resolved at runtime, so you'd get >> code like "DROP INDEX <> ON users;"." >> >> [1] >> https://groups.google.com/**forum/?fromgroups#!topic/** >> django-developers/usFXJvpelmI<https://groups.google.com/forum/?fromgroups#!topic/django-developers/usFXJvpelmI> >> >> Am I correct to assume that the plan is to allow migration files in >> python as well as pseudo-SQL like above? >> In that case, I think will concentrate on just the core part of >> migrations API and nothing else as far as GSoC is concerned. >> > > The actual migration file loading/running system was never intended to be > part of the GSOC (nor my port when I was planning it) - the idea was to get > just the database API in for a release, allowing South to lose all that > code, then work on a migration file/running/dependency API for the next one. > > There's a lot more potential bikeshedding and design issues with writing a > migration-running API, so that's one of the reasons it's separated out. I'd > highly recommend focusing just on the database API - what's in South > currently can't be ported straight across, and it needs quite a bit of > cleanup (especially in the SQLite code), so it's still a decent amount of > work. > > > > Another query: >> Andrew's thread above also mentioned: >> Some of these operations are already mostly implemented (add_table, >> add_index, etc.) in backends' creation modules, but they'll need a bit >> of rearranging and separating into a full public API. I also plan to >> modify them to take model names and field names, instead of table names >> and column names, so the API is exclusively using the Django model layer >> to represent changes (there's a possibility that some changes make sense >> for schemaless databases as well, specifically renames, so it's best not >> to tie it directly to relational databases). >> >> As it happens xtrqt last year had implemented, documented and tested the >> migrations API for at least SQLite[2]. However he used explicit table >> and column names in his API methods. Obviously he put the task of table >> name translation on the API caller. Is there any consensus on the API >> design regarding this point? >> > > I feel that table names should definitely be explicit, as models expose > their expected name. Column names are harder if you accept Django fields as > valid inputs for the type - South currently uses implicit column names in > add_table (i.e. _id gets auto-added) and explicit elsewhere. I'd rather it > was explicit everywhere, and the field's column information was ignored in > the schema alteration API (it's the migration runner's job to feed it the > right stuff, I'd say). > > Don't rely too heavily on xtrqt's work from last year - the work that was > done was basically a copy of South's code into a new module with a few > minor changes. We're looking for a more extensive, clean move, with some > partial rewriting - in particular, I'd like to make the dry_run system more > sensible (or possibly drop it in favour of having a SQL generation mode > that would serve a similar purpose). > > SQL generation itself would be a nice feature - it's not always possible > (delete_index, delete_unique), but something that tries where it can, and > puts comments/invalid SQL where it can't, would be nice. > > Andrew > > > -- > 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 &
Re: [GSoC 2012] Schema Alteration API proposal
Here is a revised proposal. Abstract -- A database migration helper has been one of the most long standing feature requests in Django. Though Django has an excellent database creation helper, when faced with schema design changes, developers have to resort to either writing raw SQL and manually performing the migrations, or using third party apps like South[1] and Nashvegas[2]. [1] http://south.aeracode.org/ [2] https://github.com/paltman/nashvegas/ Clearly Django will benefit from having a database migration helper as an integral part of its codebase. >From the summary on django-developers mailing list[3], the task of building a migrations framework will involve: 1. Add a db.backends module to provide an abstract interface to migration primitives (add column, add index, rename column, rename table, and so on). 2. Add a contrib app that performs the high level accounting of "has migration X been applied", and management commands to "apply all outstanding migrations" 3. Provide an API that allows end users to define raw-SQL migrations, or native Python migrations using the backend primitives. 4. Leave the hard task of determining dependencies, introspection of database models and so on to the toolset contributed by the broader community. [3] http://groups.google.com/group/django-developers/msg/cf379a4f353a37f8 I would like to work on the 1st step as part of this year's GSoC. Implementation plan -- The idea is to have a CRUD interface to database schema (with some additional utility functions for indexing etc.) with functions like: * create_table * rename_table * delete_table * add_column and so on, which will have the *explicit* names of the table/column to be modified as its parameter. It will be the responsibility of the higher level API caller (will not be undertaken as part of GSoC) to translate model/field names to explicit table/column names. These functions will be directly responsible for modifying the schema, and any interaction with the database schema will take place by calling these functions. Most of these functions will come from South. These API functions will also have a "dry-run" or test mode, in which they will output raw SQL representation of the migration or display errors if they occur. This will be useful in: 1. The MySQL backend. MySQL does not have transaction support for schema modification and hence the migrations will be run in a dry run mode first so that any errors can be captured before altering the schema. 2. The django-admin commands sql and sqlall that return the SQL (for creation and indexing) for an app. They will capture the SQL returned from the API running in dry run mode. As for the future of the current Django creation API, it will have to be refactored (not under GSoC) to make use of the 'create' part of our new CRUD interface, for consistency purposes. The GeoDjango backends will also have to be refactored to use the new API. Since, they build upon the base code in db.backends, firstly db.backends will have to be refactored. Last year xtrqt had written, documented and tested code for at least the SQLite backend[4]. As per Andrew's suggestion, I would not be relying too much on that code but some parts can still be salvaged. [4] https://groups.google.com/ forum/?fromgroups#!searchin/django-developers/xtrqt/ django-developers/pSICNJBJRy8/Hl7frp-O-dMJ Schedule and Goal -- Week 1 : Discussion on API design and writing tests Week 2-3 : Developing the base migration API Week 4 : Developing extensions and overrides for PostgreSQL Week 5-6 : Developing extensions and overrides for MySQL Week 7-8.5 : Developing extensions and overrides for SQLite (may be shorter or longer (by 0.5 week) depending on how much of xtrqt's code is considered acceptable) Week 8.5-10: Writing documentaion and leftover regression tests, if any Week 11-12 : Buffer weeks for the unexpected I will consider my project to be successful when we have working, tested and documented migration primitives for Postgres, MySQL and SQLite. If we can develop a working fork of South to use these primitives, that will be a strong indicator of the project's success. About me and my inspiration for the project ------ I am Kushagra Sinha, a pre-final year student at Institute of Technology (about to be converted to an Indian Institute of Technology), Banaras Hindu University, Varanasi, India. I can be reached at: Gmail: sinha.kushagra Alternative email: kush [at] j4nu5 [dot] com IRC: Nick j4nu5 on #django-dev and #django Twitter: @j4nu5 github: j4nu5 I was happily using
