Request: initialize fields with built-in class defaults

[Bobby Mozumder]

Hi all,

Here’s an issue of usability that if fixed could make usage of custom fields 
simpler.

Right now fields don’t allow a built-in defaults, and you need to explicitly 
set the default parameter for model fields.  The problem is that this adds a 
ton of boilerplate code.

Using the Polls tutorial example, if I do:

>>> from polls.models import Question, Choice
>>> q = Question()

By default it’s always :

>>> type(q.pub_date)


The pub_date should always be a type .  If this was 
defined in the model constructor, then we could start to access the 
datetime.datetime class immediately, to assign data.  If I had a custom 
datetime.datetime class, I could possibly do this immediately:

>>> q = Question()
>>> q.pub_date.month = 11
>>> q.pub_date.day = 26
>>> q.pub_date.year = 2016
>>> q.save()

But right it would give the following error:

>>> q.pub_date.year = 2016
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'NoneType' object has no attribute 'year'

Is this a reasonable request?  

I’m able to do something like this now with my own custom fields that derive 
from models.SubfieldBase, but that class is deprecated, and the new 1.8 model 
initializer doesn’t do this anymore.

Thank you,

-bobby

-- 
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/1EBED647-BBA2-422B-A907-C9FBD6BC50F8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on adding a Couchbase backend

[Götz Bürkle]

Hi Mark,

Maybe the work done to support Google App Engine and its Datastore could
also be useful for you. You can find more information about that project on
https://github.com/potatolondon/djangae and
http://djangae.readthedocs.org/en/latest/db_backend/

Cheers,
Goetz

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

Re: Tips on adding a Couchbase backend

[Aymeric Augustin]

On 14 juin 2015, at 20:23, mnunberg...@gmail.com wrote:

> It would only be worthwhile trying to make a proper database-engine if the 
> rest of django would support it: Specifically, any kind of data modification 
> using SQL is currently unsupported

This is an well defined limitation. If you can make the ORM work for read 
queries, some might find it useful, even if write queries don’t work.

> and JOIN queries requires one of the sides to actually be a PK.

I believe Django only generates such joins, so you’re safe.

That said, in my view, the Django ORM is a series of layers that bridge the gap 
between a document-oriented API and SQL. I find it weird to shoehorn NoSQL 
databases into this framework when they already have a document-oriented API of 
their own…

An important part is to manage connections properly (I’m not sure what’s 
adequate for Couchbase) and to provide a solution to run tests (create a test 
database for tests, drop it when tests are finished). If you implement a 
database backend, you get this for free. Otherwise, you have to manage it 
yourself. Here’s a project that does this for ElasticSearch: 
https://github.com/Exirel/djangoes 

I hope this helps.

-- 
Aymeric.




-- 
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/67AB5D70-975E-4B2F-9AFA-52CA585072FD%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on adding a Couchbase backend

[mnunberg740]

Thanks for the advice. I imagine the emailer example is a way to show how to 
make something that’s not really a Django model into a Django model (similar to 
what Cassandra does).

Interesting point about not supporting the ecosystem - but the question is how 
much of the ecosystem (rough estimate) would actually continue to function with 
some features not present? It would only be worthwhile trying to make a proper 
database-engine if the rest of django would support it: Specifically, any kind 
of data modification using SQL is currently unsupported, and JOIN queries 
requires one of the sides to actually be a PK. Updates and insertions must 
currently be done using a strict KV API (i.e. no SQL)

I did some brief experimentation doing the nonrel fork. Things seemed to work 
initially, but it’s a constant struggle, and it involves understanding both 
Nonrel’s internals and Django’s internals (specifically, the internals of an 
older version). Is it a reasonable endeavor to try and base this engine off 
1.8? This doesn’t seem to be very recent, either 
https://code.djangoproject.com/wiki/NoSqlSupport 


> On Jun 13, 2015, at 11:46 PM, Shai Berger  wrote:
> 
> On Sunday 14 June 2015 00:13:33 Mark Nunberg wrote:
>> Hi folks!
>> 
>> I apologize in advance if this is the wrong venue for this discussion
>> 
>> I'm trying to determine the best means by which I might be able to add
>> Couchbase (http://www.couchbase.com) support to Django. I've come across
>> something called "django-nonrel" - it seems to have scarce documentation
>> and doesn't seem to have much activity as of late. I've also seen that
>> another non-relational database (Cassandra) has a django backend that
>> bypasses the nonrel fork, though its README
>> (https://github.com/r4fek/django-cassandra-engine) seems to suggest one
>> needs to use cqlengine for this?
>> 
> In addition to Tim's notes, please consider that django-cassandra-engine is 
> not a database-engine in the regular sense -- it does not seem to support 
> Django models, but only cqlengine models. You can probably use it to build a 
> Cassandra-based web application, utilizing Django's request-handling 
> facilities and other non-database-related utilities, but you will not be able 
> to use most of the Django eco-system. From your description, it is not clear 
> to me if you can do better for CouchBase, but perhaps you can.
> 
> You may also want to look at a project called django-mailer[1], which is an 
> example of "faking" Django models -- that is, taking something which isn't a 
> Django model (in this case, mail messages) and wrapping it in enough API to 
> allow it to be used in the Django admin. This practice is officially 
> supported 
> since Django 1.8, which made the model metadata APIs public.
> 
> HTH,
>   Shai.
> 
> [1] https://github.com/PirosB3/django-mailer

-- 
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/05198D86-C53E-4B9E-9811-16C4689FC568%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: how long to support Python 3.3?

[Collin Anderson]

Some more data points (to support removing 3.3 support):

I believe old versions of RHEL were the reason people needed 2.6 support. 
Unlike 2.6, I believe RHEL has never supported Python 3 except through 
"Software Collections", and the Python33 software collection EOL is Oct 
2016 (before 1.8 support ends). There is also now a Python 3.4 software 
collection.
https://access.redhat.com/support/policy/updates/rhscl

Looking at recent PyPI data gathered by Donald: 
https://caremad.io/2015/04/a-year-of-pypi-downloads/
It looks like 3.3 has less usage than Python2.6 in the Django world.
https://caremad.io/images/a-year-of-pypi-downloads/django-stacked-py-pct.png
(It also looks like 3.x usage has more than doubled over the last year. :)

On Saturday, June 13, 2015 at 7:00:55 PM UTC-4, Tim Graham wrote:
>
> Django 1.8 was the last version to support Python 3.2, which has its 
> security updates end February 2016. That means Python 3.2 users can 
> continue getting Django security updates for about 2 years after Python 
> security updates end. I am wondering if we should instead try to better 
> align the end of Python support with the end of Django support? (By the 
> way, Django 1.4 supports Python 2.5 which had its security updates end Oct 
> 2011 and since we had trouble configuring Jenkins with Python 2.5, we broke 
> compatibility a couple times in recent security releases -- now I run the 
> tests locally as needed).
>
> Let's take Python 3.3 as an example. Security updates for Python 3.3 are 
> scheduled to end in September 2017. Django 1.8 supports 3.3 and will 
> receive updates until April 2018. Given anyone using 3.3 is covered by the 
> LTS, I'm inclined to drop 3.3 support now (in Django 1.9). Alternatively, 
> the next two major releases of Django will be supported until April 2017 
> and December 2017. 
>
> I don't find Django support for 3.3 to be a big burden, but there are 
> occasional issues such as new features in 3.4 that are missing and need to 
> be backported for 3.3 (today I ran into a pull request with a need for 
> glob.escape(), so we needed a backport that works on Python 2 and Python 
> 3.3). The other consideration is that Python 3.5 will be released in 
> September, so we'd be back to 3 versions of Python 3 for Jenkins to test 
> against.
>
> Are there any users of Python 3.3 out there who find that there are big 
> obstacles to upgrading to 3.4?
>
> I think it's useful to plan ahead a bit to try to avoid cases such as the 
> enterprise users who are now stuck on Python 2.6 and Django 1.6.
>

-- 
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/b9ab444e-b152-4675-9fce-cd7192dd89dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.