Re: postgresql range types v2

2013-01-17 Thread Marco Paolini
On Thursday, January 17, 2013, Simon Litchfield wrote:

> Marco, this is great.

Thanks, did you give it a try?

>
> I wonder if it would be possible to add range fields without modifying
> django?
>
Very difficult, there are many small changes scattered around the core
django ORM and driver code


>
>
> On Monday, December 31, 2012 8:56:12 PM UTC+11, mpaolini wrote:
>>
>> Hi all,
>>
>> sorry for the noise, forget my previous mail as it was pointing to the
>> wrong commit,
>> here's the good one:
>>
>> https://github.com/mpaolini/**django/commit/**
>> b754abdeab204949510500ccb1b845**b7ad143542
>>
>> copying here the rest of the original mail:
>>
>> postgresql since version 9.2 added support for range types [1]
>> they have a nice set of specialized operators like "overlaps", "left of",
>> etc... [2]
>>
>> So I decided to work on a reference implementation for Django
>> even if it looks like psycopg2 does not fully support yet these data
>> types [3]
>>
>> The implementation is only a proof of concept and is not complete and not
>> tested
>> (but it does contain tests, of course!)
>>
>> I did:
>>   - datetime range python data type: two bounds plus inclusive/excusive
>> info (very basic!)
>>   - datetime range model field
>>   - range specific lookups for querysets
>>   - non-overlapping constraint: db-level enforced with sql CONSTRAINT and
>> model validation
>>   - some documentation
>>
>> TODO:
>>   - form, widget, modelform, localization, admin
>>   - more range types (int, bigint, etc...)
>>   - more validation against invalid ranges
>>   - better range type python implementation
>>   - more testing
>>
>> Do you like it? Any chances for it to land in master once it is
>> completed? Or is it too specialized?
>>
>> Cheers,
>>
>> Marco
>>
>> [1] 
>> http://www.postgresql.org/**docs/9.2/static/rangetypes.**html
>> [2] http://www.postgresql.org/**docs/9.2/static/functions-**
>> range.html#RANGE-OPERATORS-**TABLE
>> [3] 
>> http://archives.postgresql.**org/psycopg/2012-09/msg00051.**php
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/EXxINLYk-hgJ.
> To post to this group, send email to 
> django-developers@googlegroups.com 'django-developers@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com  'django-developers%2bunsubscr...@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.



Re: postgresql range types v2

2013-01-17 Thread Marco Paolini
On Thursday, January 17, 2013, Simon Litchfield wrote:

> Also, did you see psycopg2.extras.DateTimeRange?
>
> No, I missed that one !

Thanks I 'll see if it can be used somehow, but since the range types have
to be used by the core django code, I doubt they can be imported from a
third party library


> On Monday, December 31, 2012 8:56:12 PM UTC+11, mpaolini wrote:
>>
>> Hi all,
>>
>> sorry for the noise, forget my previous mail as it was pointing to the
>> wrong commit,
>> here's the good one:
>>
>> https://github.com/mpaolini/**django/commit/**
>> b754abdeab204949510500ccb1b845**b7ad143542
>>
>> copying here the rest of the original mail:
>>
>> postgresql since version 9.2 added support for range types [1]
>> they have a nice set of specialized operators like "overlaps", "left of",
>> etc... [2]
>>
>> So I decided to work on a reference implementation for Django
>> even if it looks like psycopg2 does not fully support yet these data
>> types [3]
>>
>> The implementation is only a proof of concept and is not complete and not
>> tested
>> (but it does contain tests, of course!)
>>
>> I did:
>>   - datetime range python data type: two bounds plus inclusive/excusive
>> info (very basic!)
>>   - datetime range model field
>>   - range specific lookups for querysets
>>   - non-overlapping constraint: db-level enforced with sql CONSTRAINT and
>> model validation
>>   - some documentation
>>
>> TODO:
>>   - form, widget, modelform, localization, admin
>>   - more range types (int, bigint, etc...)
>>   - more validation against invalid ranges
>>   - better range type python implementation
>>   - more testing
>>
>> Do you like it? Any chances for it to land in master once it is
>> completed? Or is it too specialized?
>>
>> Cheers,
>>
>> Marco
>>
>> [1] 
>> http://www.postgresql.org/**docs/9.2/static/rangetypes.**html
>> [2] http://www.postgresql.org/**docs/9.2/static/functions-**
>> range.html#RANGE-OPERATORS-**TABLE
>> [3] 
>> http://archives.postgresql.**org/psycopg/2012-09/msg00051.**php
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/shC1MhFZg4YJ.
> To post to this group, send email to 
> django-developers@googlegroups.com 'django-developers@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com  'django-developers%2bunsubscr...@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.



Reminder: pending Oracle fixes and issues

2013-01-17 Thread Shai Berger
Hi Django devs, and in particular Oracle users,

This is to remind you of fixes I proposed for the Oracle backend, which were 
mostly discussed and accepted, but seem not to have made it into the codebase 
yet. I am referring to:

- PR #393[0] - Includes two separate issues -- of which one has been handled 
by including the specific fix (% signs in table names), and the other is, to 
the 
best of my knowledge, is yet unhandled (very slow processing of numbers). This 
issue has been discussed at some length with Ian and Anssi before the 1.5 
feature freeze, and was then defined as a bug that can get in later -- but it 
didn't (I'm not sure if it is severe enough to justify inclusion now that an 
RC has been released, but I'd certainly want to see it in master).

- PR #411[1] - which fixes #10070[2] for Oracle. I don't even know if this fix 
is ready for checkin or not -- I know it fixes a bug that appears to be 
accepted, but the bug is about an undocumented feature (which is, 
nevertheless, available for other backends). I haven't added documentation or 
tests; my question on the bug about this was left unanswered. While I did make 
the PR before the feature freeze, I have no expectations of this getting into 
1.5 -- but I would like to see it go in sometime...

Besides these two, I would like to continue the discussion on PR #402[3]; it 
suggests adding a flag to Oracle's DATABASE_OPTIONS, to control how it returns 
explicit expressions from raw sql ("select 1.5 from ..."). The current backend 
(also after inclusion of PR #393) returns a python Decimal, which is the Right 
Thing(tm) to do for Oracle, but breaks cross-database compatibility (Decimals 
don't mix well with floats). In the previous discussion[4], Anssi essentially 
rejected the cross-database issue, asserting that this needs to be handled 
query-by-query, and by implication, on a backend-specific basis; I think that 
requiring reusable apps to include backend-specific code, when they use common, 
standard sql; and with no simple fix for the user, is the worse choice here 
(although the user can do what I did, and use a customized backend).

Thanks for your attention,

Shai.

[0] https://github.com/django/django/pull/393
[1] https://github.com/django/django/pull/411
[2] https://code.djangoproject.com/ticket/10070
[3] https://github.com/django/django/pull/402
[4] https://groups.google.com/d/msg/django-developers/4BNkJyGez9A/1yBVs-NL2h0J

-- 
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 contributor

2013-01-17 Thread Michael Lauria
Hi, I'd like to get involved, but I have no idea where to start. Could 
anyone suggest something? Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/6Kt-7_WnqeEJ.
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: Reminder: pending Oracle fixes and issues

2013-01-17 Thread Jani Tiainen

17.1.2013 15:50, Shai Berger kirjoitti:

Hi Django devs, and in particular Oracle users,

This is to remind you of fixes I proposed for the Oracle backend, which were
mostly discussed and accepted, but seem not to have made it into the codebase
yet. I am referring to:



What comes to your fix for named parameters I would give it +0. Not 
necessity but I would found it useful, specially when adding lot of 
parameters like we have to do in few places to use our legacy data.


Continuing to Oracle fixes I would also like to see incorporated fix for 
bug #19606 [2] for unicode support and Django detection algorithm due 
changes between cx_Oracle versions 5.0.x and 5.1.x. PR #650 [1] exists 
for that.



[1] https://github.com/django/django/pull/650
[2] https://code.djangoproject.com/ticket/19606

--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

--
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: Reminder: pending Oracle fixes and issues

2013-01-17 Thread Anssi Kääriäinen
On 17 tammi, 15:50, Shai Berger  wrote:
> Besides these two, I would like to continue the discussion on PR #402[3]; it
> suggests adding a flag to Oracle's DATABASE_OPTIONS, to control how it returns
> explicit expressions from raw sql ("select 1.5 from ..."). The current backend
> (also after inclusion of PR #393) returns a python Decimal, which is the Right
> Thing(tm) to do for Oracle, but breaks cross-database compatibility (Decimals
> don't mix well with floats). In the previous discussion[4], Anssi essentially
> rejected the cross-database issue, asserting that this needs to be handled
> query-by-query, and by implication, on a backend-specific basis; I think that
> requiring reusable apps to include backend-specific code, when they use 
> common,
> standard sql; and with no simple fix for the user, is the worse choice here
> (although the user can do what I did, and use a customized backend).

Even worse than requiring backend-specific code in 3rd party apps is
to force everybody using the app to set a global flag. This might
break other 3rd party apps or the user's code. This is not OK, an app
should not force the user to set a global flag.

For the compatibility issue: both MySQL and PostgreSQL return Decimal
for "select 1.5". SQLite returns float. If you want to write cross-db
compliant raw SQL you have to deal with leaky abstractions.

 - 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.



Re: new contributor

2013-01-17 Thread Aymeric Augustin
Le 17 janv. 2013 à 16:00, Michael Lauria  a écrit :

> Hi, I'd like to get involved, but I have no idea where to start. Could anyone 
> suggest something? Thanks in advance.

Hi Michael,

The documentations contains a wealth of information about getting involved:
https://docs.djangoproject.com/en/dev/internals/contributing/

There's even a page dedicated to people in your situation:
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/

If you have more specific questions feel free to ask them here or on 
#django-dev on FreeNode.

Regards,

-- 
Aymeric.



-- 
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: new contributor

2013-01-17 Thread donarb
On Jan 17, 7:00 am, Michael Lauria  wrote:
> Hi, I'd like to get involved, but I have no idea where to start. Could
> anyone suggest something? Thanks in advance.

https://code.djangoproject.com/#Gettinginvolved

-- 
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: new contributor

2013-01-17 Thread CJ Goldsmith
There are some great videos that reference this situation if you search for the 
djangocon 2012 videos

-CJ-

Sent from my iPhone

On Jan 17, 2013, at 7:00 AM, Michael Lauria  wrote:

> Hi, I'd like to get involved, but I have no idea where to start. Could anyone 
> suggest something? Thanks in advance.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-developers/-/6Kt-7_WnqeEJ.
> 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.



Re: postgresql range types v2

2013-01-17 Thread Russell Keith-Magee
On Mon, Dec 31, 2012 at 5:56 PM, Marco Paolini wrote:

> Hi all,
>
> sorry for the noise, forget my previous mail as it was pointing to the
> wrong commit,
> here's the good one:
>
> https://github.com/mpaolini/**django/commit/**
> b754abdeab204949510500ccb1b845**b7ad143542
>
> copying here the rest of the original mail:
>
> postgresql since version 9.2 added support for range types [1]
> they have a nice set of specialized operators like "overlaps", "left of",
> etc... [2]
>
> So I decided to work on a reference implementation for Django
> even if it looks like psycopg2 does not fully support yet these data types
> [3]
>
> The implementation is only a proof of concept and is not complete and not
> tested
> (but it does contain tests, of course!)
>
> I did:
>  - datetime range python data type: two bounds plus inclusive/excusive
> info (very basic!)
>  - datetime range model field
>  - range specific lookups for querysets
>  - non-overlapping constraint: db-level enforced with sql CONSTRAINT and
> model validation
>  - some documentation
>
> TODO:
>  - form, widget, modelform, localization, admin
>  - more range types (int, bigint, etc...)
>  - more validation against invalid ranges
>  - better range type python implementation
>  - more testing
>
> Do you like it? Any chances for it to land in master once it is completed?
> Or is it too specialized?
>

Hi Marco,

Great work!

As for getting this into master -- we have to dance a fine line between
supporting all the great features of a database like PostgreSQL, and
guaranteeing cross-database compatibility.

So - while I'm not sure there's a place for this in core (unless you can
demonstrate how to implement range types on other backends), it should be
*possible* to use this library as a third party extension. If there is any
interface or refactoring that that can be done to the database backend API
that would make this possible, I'm definitely open to making those changes.

The other thing I'd suggest is to look at others doing similar work. For
example, Zachary Voase has been working on extensions to Django's
PostgreSQL backend to support a whole lot of extra PostgreSQL features[1].
>From the look of it, he hasn't got to range types yet, so what you've done
here could probably be added as part of that project. PostgreSQL has tons
of great features, and it would be great to be able to expose them in a
clean way to Django developers; better yet would be to expose them all as a
single extension library.

[1] https://github.com/zacharyvoase/django-postgres

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.



Re: Github tags

2013-01-17 Thread Yo-Yo Ma
Sorry to be a pest, but will you guys end up adding a Git tag for RC-1?

On Sunday, October 28, 2012 10:38:00 PM UTC-4, Matt Austin wrote:
>
> Hi, 
>
> Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 
> alpha tagged on the github repository? The tagging seems to have 
> fallen behind with these releases. 
>
> Thanks, 
>
> -- 
> Matt 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/k5kOIGBuO_AJ.
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.