Re: Schema evolution

[Jeroen Ruigrok van der Werven]

Brant,

On 4/24/06, Brant Harris <[EMAIL PROTECTED]> wrote:
> I've created a proposal for working all of the Schema Evolution tidbits out:
> http://code.djangoproject.com/wiki/SchemaEvolutionProposal
>
> If you get a chance to read and comment, I'd appreciate.

I noticed in the code that you have auto_add_now, whereas it should be
auto_now_add. At least according to
http://www.djangoproject.com/documentation/model_api/

-- 
Jeroen Ruigrok van der Werven

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: .delete() a little too eager?

[Jeff Forcier]

I found this a few months ago and created a patch for it:

http://code.djangoproject.com/ticket/1007

I'm not at all sure that it will patch correctly against anything
recent, but it should be pretty obvious what I did, so you should be
able to tweak it for whatever version you have checked out.

I never found the time to do unit tests for it, which is one reason it
hasn't been considered for a merge into trunk. If you have the time for
this, that'd be great, otherwise I will try to find some time in the
near future.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Ticket review please? 1584

[Jeroen Ruigrok van der Werven]

Could someone a little more intimate with the source code please
review the follow ticket:

http://code.djangoproject.com/ticket/1584

Also see the discussion on django-users about this.

Thanks,

-- 
Jeroen Ruigrok van der Werven

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Schema evolution

[Derek Anderson]

jeroen, brant, ilias, etc:

schema evolution was an idea suggested and specifically granted for the
SoC project.  i don't know who here was involved with ranking the
proposals, but for better or worse mine was accepted.  to a certain
extent i expect this to come with a effort not to trivialize my
existence here before i can even get off the ground.

more to the point: if you have and ideas/recommendations, i'd love to
hear them.  if you have questions regarding my abilities/qualifications,
i'll answer those too.  but in terms of going forward with your own
implementations, i ask that you put them on hold for just a little
while.  if i fail miserably you won't be but a month or two behind
schedule.  surely, until then, there are other areas in which you could
contribute without so sharply undercutting my chance for success.

thank you,
-- derek


Jeroen Ruigrok van der Werven wrote:
> Brant,
> 
> On 4/24/06, Brant Harris <[EMAIL PROTECTED]> wrote:
>> I've created a proposal for working all of the Schema Evolution tidbits out:
>> http://code.djangoproject.com/wiki/SchemaEvolutionProposal
>>
>> If you get a chance to read and comment, I'd appreciate.
> 
> I noticed in the code that you have auto_add_now, whereas it should be
> auto_now_add. At least according to
> http://www.djangoproject.com/documentation/model_api/
> 

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Schema evolution

[Todd O'Bryan]

On May 29, 2006, at 11:09 AM, Derek Anderson wrote:

> schema evolution was an idea suggested and specifically granted for  
> the
> SoC project.  i don't know who here was involved with ranking the
> proposals, but for better or worse mine was accepted.

And I for one am very excited.

Do you have an outline somewhere, or is there a copy of your proposal  
around that we can comment on?

Todd

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Schema evolution

[Jeroen Ruigrok van der Werven]

On 5/29/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
> schema evolution was an idea suggested and specifically granted for the
> SoC project.  i don't know who here was involved with ranking the
> proposals, but for better or worse mine was accepted.  to a certain
> extent i expect this to come with a effort not to trivialize my
> existence here before i can even get off the ground.
>
> more to the point: if you have and ideas/recommendations, i'd love to
> hear them.  if you have questions regarding my abilities/qualifications,
> i'll answer those too.  but in terms of going forward with your own
> implementations, i ask that you put them on hold for just a little
> while.  if i fail miserably you won't be but a month or two behind
> schedule.  surely, until then, there are other areas in which you could
> contribute without so sharply undercutting my chance for success.

Erhm, the way I read this email answer above you sound a bit miffed.
All I did was email Brant and the list about an issue in the code on
the proposal page I thought Brant put up. If that means that "your
existence gets trivialized" and "your chance for success is sharply
undercut" I seriously have to wonder if you don't need to:

1) read emails with less emotion and/or assumptions;
2) take a break since it almost sounds as if you're overworked or stressed out.

-- 
Jeroen Ruigrok van der Werven

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: unicode.. reject?

[gabor]

Jeroen Ruigrok van der Werven wrote:
> On 5/28/06, gabor <[EMAIL PROTECTED]> wrote:
>> further debugging showed, that psycopg is at fault, because it quotes
>> byte-string params, but not unicode-string params.
>>
>> also, take an unicode string, like u"gábor" (my name :-). you can assign
>> it into a charfield, and if you save the model using sqlite3, it's going
>> to be ok. but if you do it with psycopg, you get a segmentation fault
>> (on fedora), or a bus-error (on osx). this is again a problem with psycopg.
> 
> Comment from out of nowhere: how does psycopg2 hold itself in these cases?
> 

it works fine in all the cases...

now i just have to install mysql and check that out too :)


gabor

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Schema evolution

[Derek Anderson]

proposal is here:
https://kered.org/blog/2006/05/24/summer-of-code/

it's more of a bit on a previous/related effort i did than a specific
plan for django.  i'm new to this project, and just starting my way
through your all's modeling framework.  more will be coming.

jeroen:
not miffed.  just marking a little tree in a big forest.  :)



Todd O'Bryan wrote:
> On May 29, 2006, at 11:09 AM, Derek Anderson wrote:
> 
>> schema evolution was an idea suggested and specifically granted for  
>> the
>> SoC project.  i don't know who here was involved with ranking the
>> proposals, but for better or worse mine was accepted.
> 
> And I for one am very excited.
> 
> Do you have an outline somewhere, or is there a copy of your proposal  
> around that we can comment on?
> 
> Todd
> 
> > 

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: unicode.. reject?

[Jeroen Ruigrok van der Werven]

On 5/29/06, gabor <[EMAIL PROTECTED]> wrote:
> it works fine in all the cases...

At least that's good news. I just wonder if it means that psycopg is a
dead-end for dealing with Unicode and psycopg2 should be the preferred
choice. I will try to see what I can dig up.

-- 
Jeroen Ruigrok van der Werven

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Schema evolution

[Jeroen Ruigrok van der Werven]

On 5/29/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
> proposal is here:
> https://kered.org/blog/2006/05/24/summer-of-code/

I will check it out later this week.

> it's more of a bit on a previous/related effort i did than a specific
> plan for django.  i'm new to this project, and just starting my way
> through your all's modeling framework.  more will be coming.

You will find the Django community, as far as I have known it for the
past 9 months or so, very enthusiastic and helpful. In general there's
a large consensus build-up towards decisions (you might be familiar
with +1, 0, -1 votes on email lists, if not, see
http://www.djangoproject.com/documentation/contributing/ - Deciding on
features).

So in other words: welcome.

> jeroen:
> not miffed.  just marking a little tree in a big forest.  :)

That's good to know, because people *will* read and react to your
proposals. All of this to get Django better.

Like I said, at the end of the week I will comment, since I should
have some free time then.

-- 
Jeroen Ruigrok van der Werven

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: unicode.. reject?

[gabor]

Jeroen Ruigrok van der Werven wrote:
> On 5/29/06, gabor <[EMAIL PROTECTED]> wrote:
>> it works fine in all the cases...
> 
> At least that's good news. I just wonder if it means that psycopg is a
> dead-end for dealing with Unicode and psycopg2 should be the preferred
> choice. I will try to see what I can dig up.
> 

hmm, it depends on what do you call "unicode" :)

for example,if you keep EVERYTHING in utf-8 encoded bytestrings,
and:
- generate utf-8 webpages
- set up the database to store data in utf-8,

then you can easily store-and-handle any kind of text (japanese, arabic, 
whatever) in your application even with psycopg1 fine.

but by "unicode" you mean python unicode-strings,hmm..then probably 
psycopg2. but then, to have a nice unicode-integration in django, we'd 
need to convert EVERYTHING to unicode..httpRequest, httpResponse etc. 
(as at http://code.djangoproject.com/wiki/UnicodeInDjango).

i'd love to have django in unicode, but it's not an easy change. and 
also i'm not sure what would the authors say :)

gabor

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: unicode.. reject?

[Jeroen Ruigrok van der Werven]

On 5/29/06, gabor <[EMAIL PROTECTED]> wrote:
> hmm, it depends on what do you call "unicode" :)

Not just UTF-8. ;)

> for example,if you keep EVERYTHING in utf-8 encoded bytestrings,
> and:
> - generate utf-8 webpages
> - set up the database to store data in utf-8,
>
> then you can easily store-and-handle any kind of text (japanese, arabic,
> whatever) in your application even with psycopg1 fine.

Good. Since for my dictionary project using Django I need to use
Japanese, Korean, Chinese, Tibetan at least.

> but by "unicode" you mean python unicode-strings,hmm..then probably
> psycopg2. but then, to have a nice unicode-integration in django, we'd
> need to convert EVERYTHING to unicode..httpRequest, httpResponse etc.
> (as at http://code.djangoproject.com/wiki/UnicodeInDjango).

Right.

> i'd love to have django in unicode, but it's not an easy change. and
> also i'm not sure what would the authors say :)

As far as I know it that page is the official stance of Unicode in
Django. Georg (hugo) is the prime instigator and I will help out on
this since I will probably need some of this functionality.

-- 
Jeroen Ruigrok van der Werven

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Schema evolution

[Ilias Lazaridis]

Derek Anderson wrote:
> jeroen, brant, ilias, etc:
> 
> schema evolution was an idea suggested and specifically granted for the
> SoC project.  i don't know who here was involved with ranking the
> proposals, but for better or worse mine was accepted.  to a certain
> extent i expect this to come with a effort not to trivialize my
> existence here before i can even get off the ground.

I understand that you feel this way.

But I assure you, that I do not trivialize your existence.

> more to the point: if you have and ideas/recommendations, i'd love to
> hear them.  if you have questions regarding my abilities/qualifications,
> i'll answer those too.  but in terms of going forward with your own
> implementations, i ask that you put them on hold for just a little
> while.  if i fail miserably you won't be but a month or two behind
> schedule.  surely, until then, there are other areas in which you could
> contribute without so sharply undercutting my chance for success.

Again I like to tell you that I understand the way you feel and react.

Your suggestions are rational.

But, I for my case cannot fall 1 or 2 months behind the schedule.

To be able to continue the Django Audit...:

http://case.lazaridis.com/multi/wiki/DjangoAudit

...I need a _simple_ evolution mechanism immediately ("add field" 
functionality, will be available most possibly tomorrow).

If you read the plan, you will notice that I take the existent SoC 
project (and thus you) fully in account:

http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution?version=5

-

(btw: I've noticed this old thread by 'accident')

> thank you,
> -- derek
> 
> 
> Jeroen Ruigrok van der Werven wrote:
>> Brant,
>>
>> On 4/24/06, Brant Harris <[EMAIL PROTECTED]> wrote:
>>> I've created a proposal for working all of the Schema Evolution tidbits out:
>>> http://code.djangoproject.com/wiki/SchemaEvolutionProposal
>>>
>>> If you get a chance to read and comment, I'd appreciate.
>> I noticed in the code that you have auto_add_now, whereas it should be
>> auto_now_add. At least according to
>> http://www.djangoproject.com/documentation/model_api/
>>
> 
> > 
> 


-- 
http://lazaridis.com


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Ticket review please? 1584

[Luke Plant]

On Monday 29 May 2006 16:08, Jeroen Ruigrok van der Werven wrote:
> Could someone a little more intimate with the source code please
> review the follow ticket:
>
> http://code.djangoproject.com/ticket/1584

In case you didn't notice, this is now done.

Luke

-- 
"The one day you'd sell your soul for something, souls are a glut."

Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Ticket review please? 1584

[Jeroen Ruigrok van der Werven]

On 5/29/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> In case you didn't notice, this is now done.

Thanks a lot Luke for handling it promptly, much appreciated. I'll
test this in my case.

-- 
Jeroen Ruigrok van der Werven

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: unicode.. reject?

[gabor]

Jeroen Ruigrok van der Werven wrote:
> On 5/29/06, gabor <[EMAIL PROTECTED]> wrote:>
>> but then, to have a nice unicode-integration in django, we'd
>> need to convert EVERYTHING to unicode..httpRequest, httpResponse etc.
>> (as at http://code.djangoproject.com/wiki/UnicodeInDjango).
> 
> 
> As far as I know it that page is the official stance of Unicode in
> Django. Georg (hugo) is the prime instigator and I will help out on
> this since I will probably need some of this functionality.
> 

i'm also willing to help with this task... but..do i understand this 
correctly, that it's agreed that django is going to switch to unicode?

because i don't really see a way to have it coexist with the current 
bytestring-based framework.

gabor

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: unicode.. reject?

[Ivan Sagalaev]

gabor wrote:

>i'm also willing to help with this task... but..do i understand this 
>correctly, that it's agreed that django is going to switch to unicode?
>  
>
Being one of the proponent of the all-unicode way back when it was 
proposed I should say that the more I think of it the more I'm afraid 
that it can create just as much problems as it will solve. Today there 
is a convention that Django works everywhere with byte strings except 
some rare cases where it is convinient to use Python's built-in unicode 
functions (these cases include counting length in validation code and 
various string conversions in filters like in the unapplied patch in 
ticket http://code.djangoproject.com/ticket/924). Using this convention 
one can write international apps without worries since all messy things 
are made inside the framework.

If we change this convention to using Python's unicode everywhere we 
will hardly win anything except some feeling of a more "pure" approach. 
At least _I_ can't see any gain :-). However there will be some 
disadvantages that I think are serious:

- I heard that many 3rd party libraries don't work with unicode so a 
user will be forced to do some coversions manually
- byte strings is a default string type in Python and is more widely 
used than unicode, I'm afraid many people in ASCII-world will be 
resistant to switching all their coding to unicode because they can't be 
sure that it works right because they can't test it easily themselves

So may be Django should just wait for Python 3000 when unicode string 
will become default ones and developers would be more widely aware of 
this change.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: .delete() a little too eager?

[[EMAIL PROTECTED]]

Hm. It seems to me that this issue can be solved by enhancing the
declarative model side of Django. The problem is that you can't really
differentiate between "part/whole" relationships, and associations. You
should be able to say that an object is a part of a different object. I
believe you can use belongs_to in Ruby on Rails to do this (but I've
might be wrong, I've never actually tried RoR). Anyway, I suppose you
could add a keyword to the ForeignKeyField, e.g. "belongs_to: True".

This way you can map the three most common "on delete" options for
foreign keys. A nullable foreign key maps to "set null", a regular
foreign key maps to restrict, and a "belongs_to" foreign key maps to
"cascade".

Now, this information can also be used in the edit form. Objects that
are part of some other object should naturally use the edit_inline
option, and thus appear as part of the containing object. If the edit
inline option is improved so as not to rely on the core= stuff but
instead has separate create/delete buttons, I think that would be a
great improvement.

The application I've based my example on actually has subprojects as
components of projects, so you'd actually need two levels of inline
editing, and there are actually two different objects that are part of
the subproject. If I could just declare that the subproject is part of
the project, and that it should be edited in stacked form, and then
have the contained reductions be editable in tabular form inside each
subproject, I'd be a very happy man.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

OT: arbitrary precision decimals for Python?

[Todd O'Bryan]

Sorry for the OT post, but what do people use for arbitrary precision  
decimals in Python?

I would think it's in the standard libraries somewhere, but I must be  
googling the wrong terms.

Todd

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Custom manipulators

[Luke Plant]

Has anyone tried to use Django's manipulators and forms for the case 
where you only want a few fields to be editable, and the rest to keep 
the original values?  If so, has anyone found a way of doing this that, 
to put it bluntly, doesn't suck?

The cookbook has this:

http://code.djangoproject.com/wiki/CookBookManipulatorWithPostpopulatedFields

This sucks for obvious reasons -- you have to go through every field in 
your model and copy it's data into the new_data dictionary, at the same 
time converting it all to string values (which involves knowing how 
Django does this internally, which becomes pretty complicated with 
DateTimeFields etc).


The other main method is custom manipulators with only a few fields.  
This sucks because it violates DRY - you have to tell the custom 
manipulator the information that AutomaticManipulators deduce 
automatically from the model definition.  You then have to copy your 
information from the new_data dict to the model object - a pain if it 
contains DateTimeFields, since you have to combine multiple pieces of 
data.  Plus, if you want FileUpload fields, it also requires copying a 
few chunks of code from AutomaticManipulator.

In short, I was hoping to do something like this:

class MyManipulator(MyModel.ChangeManipulator):
   limit_to = ['my_text_field', 'my_date_field', 'my_upload_field']

...or, at the very least write some code that would have the same 
result, and only have to write the guts of it once, and be reasonably 
sure it would continue working.

But I haven't been able to do this, and after a few hours trying to Do 
It Right, I almost gave up went to manual form creation and processing.  
I eventually worked out that the custom manipulator method isn't too 
bad, and that's what I'm using now, but it's far from ideal.

This seems like a fairly common use case i.e. a create/update form, but 
with some fields that can't be edited.  Would it be possible to fix 
AutomaticManipulator and co to make this easier?   Are there any 
gotchas people can think of (I imagine validators that check multiple 
fields might be one)?  If I came up with a patch to make this easier, 
would the core devs be interested? 

Cheers,

Luke

-- 
"The one day you'd sell your soul for something, souls are a glut."

Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: OT: arbitrary precision decimals for Python?

[Nicola Larosa (tekNico)]

> Sorry for the OT post, but what do people use for arbitrary
> precision decimals in Python?
>
> I would think it's in the standard libraries somewhere, but I
> must be googling the wrong terms.

It's called...  [drum roll]

decimal! ;-)

http://docs.python.org/lib/module-decimal.html

-- 
Nicola Larosa - http://www.tekNico.net/


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: OT: arbitrary precision decimals for Python?

[Todd O'Bryan]

D'oh. Thanks!

(And that doesn't come up at all if you google the words "arbitrary"  
"precision" "Python", strangely.)

Todd

On May 29, 2006, at 6:21 PM, Nicola Larosa (tekNico) wrote:

>
>> Sorry for the OT post, but what do people use for arbitrary
>> precision decimals in Python?
>>
>> I would think it's in the standard libraries somewhere, but I
>> must be googling the wrong terms.
>
> It's called...  [drum roll]
>
> decimal! ;-)
>
> http://docs.python.org/lib/module-decimal.html
>
> -- 
> Nicola Larosa - http://www.tekNico.net/
>
>
> >


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: EVOLUTION - Add Field Schema Evolution Support

[Ilias Lazaridis]

Ilias Lazaridis wrote:
> After reviewing the relevant source code base a little, I have started 
> with the implementation of the schema evolution skeleton (which will 
> contain a functional "Add Field" support).
> 
> http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution
> 
> With a very small assistance from the team (mostly subjecting constructs 
> and of course review of resulting code), I estimate to have a working 
> solution within 3 days.
...

The "Add Field" functionality is nearly ready.

A small problem:

I am wondering how to retrieve a collection of columns within a table, 
whilst using the standard python dbapi2 functionality.

pyodbc has nice functions available:
http://pyodbc.sourceforge.net/docs.html#cursor_columns
http://pyodbc.sourceforge.net/docs.html#catalog

but it looks that they are not pydbapi2 specific, as looking at the 
Python dbapi2 doc found on the net, does not show any catalog functions:

http://www.egenix.com/files/python/DatabaseAPI-2.0.html

-

The sqlite3 python bindings do not state anything about catalog 
functions (or something similar), too:

http://initd.org/pub/software/pysqlite/doc/usage-guide.html#python-database-api-2-0-compliance

-

I've looked within the django code, but couldn't find a way.

Have I overseen anything, or is this functionality not available?

Can I use alternatively an SQL statement for this?

I am OO, and not familar with SQL, thus I would be very thankful for an 
concrete example.

.

-- 
http://lazaridis.com


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: EVOLUTION - Add Field Schema Evolution Support

[James Bennett]

On 5/29/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> The "Add Field" functionality is nearly ready.

You are aware that a full implementation of schema evolution for
Django was accepted as a Google Summer of Code project, right?

-- 
"May the forces of evil become confused on the way to your house."
  -- George Carlin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: EVOLUTION - Add Field Schema Evolution Support

[Ilias Lazaridis]

James Bennett wrote:
> On 5/29/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
>> The "Add Field" functionality is nearly ready.
> 
> You are aware that a full implementation of schema evolution for
> Django was accepted as a Google Summer of Code project, right?

Yes, I am.

http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution

.

-- 
http://lazaridis.com


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: EVOLUTION - Add Field Schema Evolution Support

[DavidA]

> I am wondering how to retrieve a collection of columns within a table,
> whilst using the standard python dbapi2 functionality.

Do you mean cursor.description?

cursor = connection.cursor()
cursor.execute('select * from blog_post where 1 = 0')
for col in cursor.description:
print col

Each col is a 7-item sequence containing column name, type_code,
display_size, internal_size, precision, scale, and null_ok)

http://www.python.org/dev/peps/pep-0249/

-Dave


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: EVOLUTION - Add Field Schema Evolution Support

[Ilias Lazaridis]

DavidA wrote:
>> I am wondering how to retrieve a collection of columns within a table,
>> whilst using the standard python dbapi2 functionality.
> 
> Do you mean cursor.description?
> 
> cursor = connection.cursor()
> cursor.execute('select * from blog_post where 1 = 0')
> for col in cursor.description:
> print col
> 
> Each col is a 7-item sequence containing column name, type_code,
> display_size, internal_size, precision, scale, and null_ok)
> 
> http://www.python.org/dev/peps/pep-0249/

Thanks!

Although this cannot be used as the final solution, it keeps me running 
now, thus I can test the code.

sqlite3 has problems with this function, it returns only the column name:

http://initd.org/pub/software/pysqlite/doc/usage-guide.html#python-database-api-2-0-compliance

Additionally, it looks that "description" will be empty, if no rows are 
returned.

But as said, I can continue with testing now!

.

-- 
http://lazaridis.com


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

inserting aggregates in one transaction

[shaunc]

Hello,

I tried using @transaction.commit_on_success to insert an object whose
pieces are in (sub)tables.

Conceptually, this should all be part of one transaction. However,
django doesn't have the new id available, and so the operation fails
(it tries to use "null" for the foreign key in the subtable, which
breaks the db constraint.

In my "roll your own" db business logic, which I'm porting from, I
always did the "next(sequence_for_the_id)" in postgres (which I use) in
a separate sql statement so I would have the id which I'd fill in in my
object even before the transaction ended. (On rollback the entire
object gets thrown out anyway, since its new.) Apparently, Django
doesn't do this

(In some other dbs, this is easier, as they return the primary key from
"insert".)

Are there any hooks available for this? Or, I would be grateful if
someone with familiarity with the source tell me where I should dig if
I wanted to put this in? (And whether it would be worth the while? Just
getting the id should be fairly local, but then it needs to be
propagated.)

Also, is this a useful feature for others?

Thanks,
- Shaun

PS on a related note, it would be very helpful if I could activate "on
delete cascade" (to say nothing of the related modifiers for
constraints). I have similar questions about that.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: .delete() a little too eager?

[shaunc]

Ah - I just asked the group about a related issue: creating "wholes" in
one transaction.


Support for specification of part/whole relationships would be useful
both for creation and insertion. Ideally, I wouldn't have to use
@transaction.commit_on_success, as I was trying to do...

class Whole( Model ):
i = IntegerField()

class Part( Model ):
whole = ForeignKey( Whole, related_name = 'parts', belongs_to =
True )
j = IntegerField()


And then, for creation of whole together with parts, either:

@transaction.commit_on_success
def create( ):
whole = Whole( i = 1 )
whole.parts.create( j = 10 )
whole.parts.create( j = 20 )
return whole

Or, more succintly, but perhaps a bit unwieldly in practice:

whole = Whole( i = 1, create_parts = ( { 'j': 10 }, { 'j': 20 } ) )

(where 'create_' is magic keyword prefix for the related set; it
expects a sequence of keyword dictionaries.)

And of course, whole.delete() would also delete the parts
-
(Note: I'm using this for bulk load of data coming in over web
crawlers. It leaves a mess if just half the data gets in, and there is
enough of it, hitting often enough, that this is probably going to
happen eventually.)


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Custom manipulators

[Ivan Sagalaev]

Luke Plant wrote:

>Has anyone tried to use Django's manipulators and forms for the case 
>where you only want a few fields to be editable, and the rest to keep 
>the original values?
>
I'm doing it very often. I have some frankenstein user model which is 
editable partly in one form, partly in another and third form edits data 
from my User model and contrib.auth's User model in together :-)

>In short, I was hoping to do something like this:
>
>class MyManipulator(MyModel.ChangeManipulator):
>   limit_to = ['my_text_field', 'my_date_field', 'my_upload_field']
>  
>
You are looking for undocumented "follow":

class MyManipulator(MyModel.ChangeManipulator):
  def __init__(self, id):
MyModel.ChangeManipulator.__init__(self, id, follow={
  'my_text_field': False,
  'my_date_field': False,
  'my_upload_field': False,
})

Manipulator will look only for fields in its "follow" dict where their 
values evaluates to "true". A default manipulator has its "follow" 
prefilled with editable fields from a model and a "follow" parameter 
that is passed in the constructor will update those values.

Similarly this way you can include non-editable fields that don't get in 
by default, just pass them with "True" value.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: inserting aggregates in one transaction

[Ian Holsman]

Hi Shaun.

I've done something similar to this using the dispatcher.

in http://svn.zyons.python-hosting.com/trunk/zilbo/common/forum/ 
models.py  (at the VERY bottom)
I use the signals to update summary tables .. I'm using pre_save..  
but you should be able to get what you need with the post_save version.

--I
On 30/05/2006, at 2:17 PM, shaunc wrote:

>
> Hello,
>
> I tried using @transaction.commit_on_success to insert an object whose
> pieces are in (sub)tables.
>
> Conceptually, this should all be part of one transaction. However,
> django doesn't have the new id available, and so the operation fails
> (it tries to use "null" for the foreign key in the subtable, which
> breaks the db constraint.
>
> In my "roll your own" db business logic, which I'm porting from, I
> always did the "next(sequence_for_the_id)" in postgres (which I  
> use) in
> a separate sql statement so I would have the id which I'd fill in  
> in my
> object even before the transaction ended. (On rollback the entire
> object gets thrown out anyway, since its new.) Apparently, Django
> doesn't do this
>
> (In some other dbs, this is easier, as they return the primary key  
> from
> "insert".)
>
> Are there any hooks available for this? Or, I would be grateful if
> someone with familiarity with the source tell me where I should dig if
> I wanted to put this in? (And whether it would be worth the while?  
> Just
> getting the id should be fairly local, but then it needs to be
> propagated.)
>
> Also, is this a useful feature for others?
>
> Thanks,
> - Shaun
>
> PS on a related note, it would be very helpful if I could activate "on
> delete cascade" (to say nothing of the related modifiers for
> constraints). I have similar questions about that.
>
>
> >


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

RE: inserting aggregates in one transaction

[Shaun Cutts]

Ian,

Thanks. Your code looks concise, but a bit mysterious (maybe it's the time
of night). Is this a way to get extra events triggered in a db transaction,
or is it just inside a single web request?

As far as I can tell, you don't seem to be insisting on having one
transaction; if you are, are you using psychopg backend? How is it able to
get the ids of previously created objects (in the same transaction)? I'd
assumed you needed to pre-increment the sequence to generate a new id by
hand, then plug this value in on insert.

Ah -- ok, in your case you may be in one transaction, but you don't need the
id of the thing created (witness: if instance.id == None: ... :))

Some background: I'm trying to automate bulk load of data from web-crawlers.
These loads happen often enough that, if I don't enforce atomicity, I'll
have a good chance of ending up with a mess in the db when one gets
interrupted for some random reason.

- Shaun


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---