innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity
django1/docs/ref/contrib/postgres/index.txt

29 lines
1.2 KiB
Plaintext
Raw Normal View History

Added array field support for PostgreSQL. The first part of django.contrib.postgres, including model and two form fields for arrays of other data types. This commit is formed of the following work: Add shell of postgres app and test handling. First draft of array fields. Use recursive deconstruction. Stop creating classes at lookup time. Add validation and size parameter. Add contained_by lookup. Add SimpleArrayField for forms. Add SplitArrayField (mainly for admin). Fix prepare_value for SimpleArrayField. Stop using MultiValueField and MultiWidget. They don't play nice with flexible sizes. Add basics of admin integration. Missing: - Tests - Fully working js Add reference document for django.contrib.postgres.fields.ArrayField. Various performance and style tweaks. Fix internal docs link, formalise code snippets. Remove the admin code for now. It needs a better way of handing JS widgets in the admin as a whole before it is easy to write. In particular there are serious issues involving DateTimePicker when used in an array. Add a test for nested array fields with different delimiters. This will be a documented pattern so having a test for it is useful. Add docs for SimpleArrayField. Add docs for SplitArrayField. Remove admin related code for now. definition -> description Fix typo. Py3 errors. Avoid using regexes where they're not needed. Allow passing tuples by the programmer. Add some more tests for multidimensional arrays. Also fix slicing as much as it can be fixed. Simplify SplitArrayWidget's data loading. If we aren't including the variable size one, we don't need to search like this.
2014-03-27 00:44:21 +08:00
``django.contrib.postgres``
===========================
PostgreSQL has a number of features which are not shared by the other databases
Django supports. This optional module contains model fields and form fields for
a number of PostgreSQL specific data types.
.. note::
Django is, and will continue to be, a database-agnostic web framework. We
would encourage those writing reusable applications for the Django
community to write database-agnostic code where practical. However, we
Fixed spelling in docs.
2014-05-28 07:46:48 +08:00
recognize that real world projects written using Django need not be
Added array field support for PostgreSQL. The first part of django.contrib.postgres, including model and two form fields for arrays of other data types. This commit is formed of the following work: Add shell of postgres app and test handling. First draft of array fields. Use recursive deconstruction. Stop creating classes at lookup time. Add validation and size parameter. Add contained_by lookup. Add SimpleArrayField for forms. Add SplitArrayField (mainly for admin). Fix prepare_value for SimpleArrayField. Stop using MultiValueField and MultiWidget. They don't play nice with flexible sizes. Add basics of admin integration. Missing: - Tests - Fully working js Add reference document for django.contrib.postgres.fields.ArrayField. Various performance and style tweaks. Fix internal docs link, formalise code snippets. Remove the admin code for now. It needs a better way of handing JS widgets in the admin as a whole before it is easy to write. In particular there are serious issues involving DateTimePicker when used in an array. Add a test for nested array fields with different delimiters. This will be a documented pattern so having a test for it is useful. Add docs for SimpleArrayField. Add docs for SplitArrayField. Remove admin related code for now. definition -> description Fix typo. Py3 errors. Avoid using regexes where they're not needed. Allow passing tuples by the programmer. Add some more tests for multidimensional arrays. Also fix slicing as much as it can be fixed. Simplify SplitArrayWidget's data loading. If we aren't including the variable size one, we don't need to search like this.
2014-03-27 00:44:21 +08:00
database-agnostic. In fact, once a project reaches a given size changing
the underlying data store is already a significant challenge and is likely
to require changing the code base in some ways to handle differences
between the data stores.
Fixed spelling in docs.
2014-05-28 07:46:48 +08:00
Added array field support for PostgreSQL. The first part of django.contrib.postgres, including model and two form fields for arrays of other data types. This commit is formed of the following work: Add shell of postgres app and test handling. First draft of array fields. Use recursive deconstruction. Stop creating classes at lookup time. Add validation and size parameter. Add contained_by lookup. Add SimpleArrayField for forms. Add SplitArrayField (mainly for admin). Fix prepare_value for SimpleArrayField. Stop using MultiValueField and MultiWidget. They don't play nice with flexible sizes. Add basics of admin integration. Missing: - Tests - Fully working js Add reference document for django.contrib.postgres.fields.ArrayField. Various performance and style tweaks. Fix internal docs link, formalise code snippets. Remove the admin code for now. It needs a better way of handing JS widgets in the admin as a whole before it is easy to write. In particular there are serious issues involving DateTimePicker when used in an array. Add a test for nested array fields with different delimiters. This will be a documented pattern so having a test for it is useful. Add docs for SimpleArrayField. Add docs for SplitArrayField. Remove admin related code for now. definition -> description Fix typo. Py3 errors. Avoid using regexes where they're not needed. Allow passing tuples by the programmer. Add some more tests for multidimensional arrays. Also fix slicing as much as it can be fixed. Simplify SplitArrayWidget's data loading. If we aren't including the variable size one, we don't need to search like this.
2014-03-27 00:44:21 +08:00
Django provides support for a number of data types which will
only work with PostgreSQL. There is no fundamental reason why (for example)
a ``contrib.mysql`` module does not exist, except that PostgreSQL has the
richest feature set of the supported databases so its users have the most
to gain.
.. toctree::
:maxdepth: 2
fields
forms