Multiple database support
For those interested in multiple database support, I have started working on it again, and posted my work-in-progress to ticket #4747. I started from trunk and added things from the multidb branch little by little, since so much has changed in that area since then. There is still a lot more that needs to be checked and a number of things to be redone. References to the default connection object are all over the codebase, there is still a lot of work left to get all of them straightened out. What is working (more or less): - using existing databases (though there might still be quirks when using different engines) - running tests - some of the management commands (eg sqlall, sqlflush, but loaddata, inspectdb or syncdb are not quite there yet) Important to mention is that relations across databases are not supported. Anyway, if anyone is interested in helping, please let me know! Koen --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Rethinking silent failures in templates
On Sat, May 17, 2008 at 11:30 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> The impression I get is that a lot of people rely on silent *variable*
> failure, but very few rely on silent *tag* failure. In fact, most
> real-world custom template tags I've seen are wired up to raise errors
> quite loudly, and the few times I've tried to write tags which fail
> silently it's been a laborious process that results in much more
> brittle code.
Well said. I can't see making ``{{ foo.bar.baz }}`` fail loudly --
it's just too big a change. It especially sucks when ``foo`` or
``bar`` is a dynamically-constructed dictionary with variable keys.
I think taking a close look at built-in *tags*, though, is a good idea
-- in general, tags should fail loudly. There are exceptions, of
course; ``{% if dict.somekey %}`` is a common idiom which translates
to something like ``if dict.has_key('somekey') and dict.somekey`` --
this is good.
A final note: if you want loud variable failures, it's a pretty
trivial task to write a template tag that echoes a variable or raises
an exception; you could then use ``{% require foo.bar.baz %}`` instead
of ``{{ foo.bar.baz }}``. I'll leave the actual implementation up to
the intrepid reader; it's just a few lines of code.
Jacob
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Composite Primary Keys
On Thu, May 8, 2008 at 7:57 PM, David Cramer <[EMAIL PROTECTED]> wrote: > I swear I saw something about work being done on this. Has anyone > begun? If not I'll gladly throw up a patch to get it into trunk. Please do. If you make sure it solves all three problems I outlined in #373 (http://code.djangoproject.com/ticket/373#comment:3) I'll make sure it gets in before the next release. Jacob --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: PostgreSQL 8.3 and casting
> I see that the Oracle backend already includes > OracleQueryconvert_values which does conversion into the backend based > on the the passed value and the field type. > > Perhaps we need to add that for PostgreSQL now? It's pretty onerous > to do the casting at the app level. > The `convert_values` routine is only used on values coming _from_ the database (via `resolve_columns`), and not on values going _to_ the database. I'm with Malcolm on not supporting this feature of automatically casting to string because the database is doing the "right thing" here. [1] However, I believe there are still parts of Django that depend on this behavior -- for instance adding a search field to a related field in the admin is one of these situations (I need to provide specifics, but don't have it on hand at the moment). [1] See http://groups.google.com/group/django-developers/browse_frm/thread/371e8743fffd3d0c. See also: http://code.djangoproject.com/ticket/6523. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
koenb wrote: > For those interested in multiple database support, I have started > working on it again, and posted my work-in-progress to ticket #4747. > ... > Anyway, if anyone is interested in helping, please let me know! I am going to need this in a month or so. Actions speak louder than words, so many thanks for your efforts. However, there were news two months ago, summarized in this thread: Yet another SoC introduction: Getting multi-db done http://groups.google.com/group/django-developers/browse_thread/thread/a0bc69e64ad8e318/ It would be nice to coordinate each one's efforts, to avoid wasting time. Ben, Daryl, any news? -- 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?hl=en -~--~~~~--~~--~--~---
Re: Many to Many Inline Editing
On May 19, 9:06 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote: > Hi, something like this?http://www.djangosnippets.org/snippets/747/ > > Hi Mon, May 19, 2008 at 8:53 PM, JReynolds <[EMAIL PROTECTED]> wrote: > > > > > > > I posted this on django-users before and didn't get much response, so > > asking here... > > > I have seen this posted a few times on the list here, but it always > > seems to become a discussion about the many to many implementation and > > move away from making it work as the one to many inline editing works > > in the newforms-admin branch. That appears to be just a drop down select? Why I need is unlike editing, including addition and removal > > > So... does anyone have a fix for being able to add/edit/delete objects > > on the other side of a many to many relationship from the edit view of > > a model? I have tried to hack up a fix by copying and changing the > > current inline implementation, but can't even get the forms to > > generate. I can elaborate on my failure if no one else has any > > working ideas... > > > I'm sure I'm not the only one that needs this and can't seem to get it > > done myself, so maybe this is a useful feature that could be added by > > someone with a better understanding of the admin internals? > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
Ah, missed that one. Anyway, I only did the easy parts (that is, getting data in and out of existing databases). Thanks for the pointer, I'll try to keep an eye on that. Koen On 20 mei, 16:56, "Nicola Larosa (tekNico)" <[EMAIL PROTECTED]> wrote: > koenb wrote: > > For those interested in multiple database support, I have started > > working on it again, and posted my work-in-progress to ticket #4747. > > ... > > Anyway, if anyone is interested in helping, please let me know! > > I am going to need this in a month or so. Actions speak louder than > words, so many thanks for your efforts. However, there were news two > months ago, summarized in this thread: > > Yet another SoC introduction: Getting multi-db > donehttp://groups.google.com/group/django-developers/browse_thread/thread... > > It would be nice to coordinate each one's efforts, to avoid wasting > time. Ben, Daryl, any news? > > -- > 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?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
On Tue, May 20, 2008 at 4:56 PM, Nicola Larosa (tekNico) <[EMAIL PROTECTED]> wrote: > It would be nice to coordinate each one's efforts, to avoid wasting > time. Ben, Daryl, any news? Currently, I have not worked on the project, since the proposal, because of job and university commitments. I plan to track the development at begin to help with the development when I get more time (over the summer). - Casper --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
I've unfortunately been too busy to make time to work on this since PyCon. The last thing I've done (after writing some code on the flight home) is to send a patch to Ben Ford. Not long after that Ben created a Mercurial repository (with my patch) and a Trac project. You'll want to contact him. I would still like to get my patch working so others (and myself) can start testing it. I won't have time this week, but so far it looks like I may be able to make some time next week. If I don't, I see if I can at least make enough time to write up the API I came up with at PyCon. -- Daryl On Tue, May 20, 2008 at 8:05 AM, Casper Jensen <[EMAIL PROTECTED]> wrote: > > On Tue, May 20, 2008 at 4:56 PM, Nicola Larosa (tekNico) > <[EMAIL PROTECTED]> wrote: >> It would be nice to coordinate each one's efforts, to avoid wasting >> time. Ben, Daryl, any news? > Currently, I have not worked on the project, since the proposal, > because of job and university commitments. I plan to track the > development at begin to help with the development when I get more time > (over the summer). > > - Casper > > > > --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Django vs. Oracle application
Hello Friends, I am newbe here and for Django as well. I wanna upgreade my previous applications that are built on php/oracle into dgango. could you please anybody guide me the real life gui application development steps by dgango/oracle. Thanks in advance. Arif Chowdhury Developer --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: PostgreSQL 8.3 and casting
On May 20, 9:01 am, Justin Bronn <[EMAIL PROTECTED]> wrote: > I'm with Malcolm on not supporting this feature of > automatically casting to string because the database is doing the > "right thing" here. [1] It's certainly the right thing to do in general. I'd like to mention one use of the implicit conversion performed by older PostgreSQL versions that I'm making use of, and others might unknowingly also: Using a CharField or SlugField as the object_id field of a generic foreign key. This allows the key to relate to both string-keyed objects and integer-keyed objects. This is fairly gross DB design; in my app it could be worked around by using surrogate ID keys (along with a lot of data munging, but that's automatable). The problem comes with targeting a generic foreign key at models from third party apps, over whose keys users don't have control. There's certainly a fix for the situation, either something simple that I've missed or perhaps adding a shim to explicitly coerce values only for desired cases. -Jim --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Django vs. Oracle application
Arif Chowdhury said the following: > I am newbe here and for Django as well. I wanna upgreade my previous > applications that are built on php/oracle into dgango. could you > please anybody guide me the real life gui application development > steps by dgango/oracle. This question would fit better on django-users - the django-developers list is for development of django itself, not general topics regarding developing with django. -- Collin Grady And ever has it been known that love knows not its own depth until the hour of separation. -- Kahlil Gibran --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
Daryl Spitzer wrote: > If I don't, I see if I can at least make enough time to write up the API > I came up with at PyCon. Please do, that would be great. -- 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?hl=en -~--~~~~--~~--~--~---
Re: Rethinking silent failures in templates
Making {{ myval }} fail loudy would break the admin app. Setting
TEMPLATE_STRING_IF_INVALID to anything other than '' also breaks it.
Here's an example: http://code.djangoproject.com/ticket/5532
This ticket has all the details: http://code.djangoproject.com/ticket/3579
Will this be fixed in newforms-admin?
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Many to Many Inline Editing
i'm sorry, probable i put similar, but not right link. maybe this one? http://marinho.webdoisonline.com/blog/p/153/ as far as i understand, google search didn't work for you. that's a pity. and seems we've got all components done for web2.0 django admin already, but unfortunately nobody has time to make it done, and we've got that silly "include-no-any-prebuilt-javascript-library-into-django(-admin)-so-let's-everyone-reinvent-the-wheel" decision On Tue, May 20, 2008 at 10:03 PM, JReynolds <[EMAIL PROTECTED]> wrote: > > > > On May 19, 9:06 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote: >> Hi, something like this?http://www.djangosnippets.org/snippets/747/ >> >> Hi Mon, May 19, 2008 at 8:53 PM, JReynolds <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> > I posted this on django-users before and didn't get much response, so >> > asking here... >> >> > I have seen this posted a few times on the list here, but it always >> > seems to become a discussion about the many to many implementation and >> > move away from making it work as the one to many inline editing works >> > in the newforms-admin branch. > > > > That appears to be just a drop down select? Why I need is unlike > editing, including addition and removal >> >> > So... does anyone have a fix for being able to add/edit/delete objects >> > on the other side of a many to many relationship from the edit view of >> > a model? I have tried to hack up a fix by copying and changing the >> > current inline implementation, but can't even get the forms to >> > generate. I can elaborate on my failure if no one else has any >> > working ideas... >> >> > I'm sure I'm not the only one that needs this and can't seem to get it >> > done myself, so maybe this is a useful feature that could be added by >> > someone with a better understanding of the admin internals? >> >> -- >> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, >> MSN: [EMAIL PROTECTED] > > > -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Many to Many Inline Editing
Hi, it is very easy to do that with newforms-admin, see http://www.djangosnippets.org/snippets/765/ how this can be done for generic relations, it would be very similar for many-to-many On Tue, May 20, 2008 at 10:32 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > > i'm sorry, probable i put similar, but not right link. > maybe this one? > http://marinho.webdoisonline.com/blog/p/153/ > > as far as i understand, google search didn't work for you. that's a pity. > > and seems we've got all components done for web2.0 django admin > already, but unfortunately nobody has time to make it done, and we've > got that silly > "include-no-any-prebuilt-javascript-library-into-django(-admin)-so-let's-everyone-reinvent-the-wheel" > decision > > On Tue, May 20, 2008 at 10:03 PM, JReynolds <[EMAIL PROTECTED]> wrote: >> >> >> >> On May 19, 9:06 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote: >>> Hi, something like this?http://www.djangosnippets.org/snippets/747/ >>> >>> Hi Mon, May 19, 2008 at 8:53 PM, JReynolds <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> >>> >>> > I posted this on django-users before and didn't get much response, so >>> > asking here... >>> >>> > I have seen this posted a few times on the list here, but it always >>> > seems to become a discussion about the many to many implementation and >>> > move away from making it work as the one to many inline editing works >>> > in the newforms-admin branch. >> >> >> >> That appears to be just a drop down select? Why I need is unlike >> editing, including addition and removal >>> >>> > So... does anyone have a fix for being able to add/edit/delete objects >>> > on the other side of a many to many relationship from the edit view of >>> > a model? I have tried to hack up a fix by copying and changing the >>> > current inline implementation, but can't even get the forms to >>> > generate. I can elaborate on my failure if no one else has any >>> > working ideas... >>> >>> > I'm sure I'm not the only one that needs this and can't seem to get it >>> > done myself, so maybe this is a useful feature that could be added by >>> > someone with a better understanding of the admin internals? >>> >>> -- >>> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, >>> MSN: [EMAIL PROTECTED] >> > >> > > > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: [EMAIL PROTECTED] > > > > -- Honza Král E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Rethinking silent failures in templates
I can add newer patch if anyone interested.
On Wed, May 21, 2008 at 2:54 AM, graham_king <[EMAIL PROTECTED]> wrote:
>
> Making {{ myval }} fail loudy would break the admin app. Setting
> TEMPLATE_STRING_IF_INVALID to anything other than '' also breaks it.
>
> Here's an example: http://code.djangoproject.com/ticket/5532
> This ticket has all the details: http://code.djangoproject.com/ticket/3579
>
> Will this be fixed in newforms-admin?
>
> >
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
using oldforms.SelectMultipleField on a custom field nets a proper select list, but I am only ever given the last value selected from the form
Ostensibly, I'm using an app very similar to the django tagging app, and the admin field used to be a text input that would do the connecting magic for you, but unfortunately we have too many users that find that complicated so I'm trying to turn it into a select box. If I define the function get_manipulator_field_objs and return a curried oldforms.SelectMultipleField I get a proper multiple select box in the admin site, but selecting more than one response seems to only hand a single value to my __set__ function. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
newforms-admin FormSet API
Hello all, The newforms-admin branch is getting close to finalizing the formset API. However, to do so we would like to run it by the developer community for ideas. I have posted a diff [1] of documentation showing the API. The diff shows the API without a leading underscore on the factory functions. Meaning in source they are defined as: * _formset_factory * _modelform_factory * _modelformset_factory * _inlineformset_factory Joseph and I believe that just dropping the leading underscore will be good enough for a finalized API. What do others think of the API? My documentation writing skills are *not* to be criticized :P However, any errors or corrections to improve them would be greatly appreciated. [1]: http://dpaste.com/hold/51750/ Brian Rosner http://oebfare.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?hl=en -~--~~~~--~~--~--~---
Re: Multi-Table Inheritance and fixtures
My fix was to simply set the parent's primary key attribute inside of th child's data, which worked for all cases with the exception of when the parent's primary key had the same name as the child's primary key. Upon the loading of a model like that, i get the error "column name is not unique." I don't see why a parent model cannot have the same field name as a child model. Is this a seperate bug? Maybe my approach towards solving the problem is incorrect? Do I have a misunderstanding of OneToOneFields? E.g. they shouldn't share pk field names (this makes sense to me)? On Mon, May 19, 2008 at 2:52 PM, Ziling Zhao <[EMAIL PROTECTED]> wrote: > Well, the main problem with the parent table being saved independently of > the children tables is that you could have a fixture that only had the > children, seperate from the parents. So if you load that fixture, they would > have no parents to associate to. > > I submitted a patch to my bug that seems to fix it in the deserialization > part by setting the parents pk before converting it to an object. This > should hopefully make it save/update correctly. > > > On Sat, May 17, 2008 at 12:41 PM, AmanKow <[EMAIL PROTECTED]> wrote: > >> >> On May 15, 6:15 pm, "Ziling Zhao" <[EMAIL PROTECTED]> wrote: >> > So, are you suggesting that on fixture loading that parents should *not* >> be >> > saved? >> > >> > Would this possibly allow you to load fixtures that don't fit in your >> model? >> > E.g. children without parents? >> >> No, what I'm suggesting is that the parent table is being saved, >> independently of the child tables. Later, the children are saved. I >> am suggesting that on load, after the parent tables are loaded, the >> children be loaded and only the child tables be touched. >> >> BTW, in your item below, parent_ptr is the primary key of the child, >> foreign keyed to the parent, implicitly created by using multitable >> inheritance. Thus MTI is just a special case of one to one where the >> one to one field is also the pk. >> >> On May 15, 6:15 pm, "Ziling Zhao" <[EMAIL PROTECTED]> wrote: >> > So, are you suggesting that on fixture loading that parents should *not* >> be >> > saved? >> > >> > Would this possibly allow you to load fixtures that don't fit in your >> model? >> > E.g. children without parents? >> > >> > >> > >> > On Sat, May 10, 2008 at 10:24 AM, AmanKow <[EMAIL PROTECTED]> wrote: >> > >> > > Above, I said: >> > > > I notice that child instances have an undocumented save_base method, >> > > > which I assume is called from the child's save. I wonder if it >> might >> > > > not be useful to have some way (r.save(exclude_parent=True) or some >> > > > such thing) in order to save the child record only. >> > >> > > But I didn't explain why I thought something like this might be useful >> > > for some types of processing and applicable to the loaddata issue. >> > >> > > For hooking up children to existing parents it would be simpler and >> > > more efficient: >> > > >>> p = Place(name="Lee's Tavern", address="Staten Island") >> > > >>> p.save() >> > > >>> r = Restaurant(serves_pizza=True, serves_hot_dogs=False, pk=p.pk) >> > > >>> r.save(child_only=True) >> > >> > > You'd have to be a bit cautious here, as r will still have the default >> > > values for the parent fields. If you are going to continue to use r, >> > > and access the parent fields in any way, the following would be >> > > appropriate after the save: >> > > >>> r = Restaurant.objects.get(pk=r.pk) >> > >> > > If indeed there is some sort of transactional issue in loaddata, >> > > always specifying that only the child be saved (it wouldn't hurt to >> > > specify it everywhere loaddata saves as it would be ignored where it >> > > wasn't pertinent) might just be the fix. >> > >> > > Wayne >> > >> > -- >> > ~Ziling Zhao >> >> >> > > > -- > ~Ziling Zhao > -- ~Ziling Zhao --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Hayat�m�z� kolayla�t�racak icatlar
thank you can you write in english iam in libya Tatyana Sveatna <[EMAIL PROTECTED]> wrote: Hayatýmýzý kolaylaþtýracak icatlarMay 8, 2008 sdc Tarafýndan | Teknoloji Kategorisine eklendi Teknoloji o kadar ilerledi ki. Bir robotun Keman çalmasý normal olmaya baþladý , yakýnda bulaþýklarý yýkayan tatlý mý tatlý, þeker mi þeker , cici mi cici kýz robotlar satýþa sunulacak ,Belki bir çoçuk gibi onu okula göndereceðiz , belkide kendimize eþ yapýp Evimizi belkide yatagýmýzý süsleyecek bu robotlarýn paslanmaya karþý korumasý inþallah düþünülmüþtür .. Gelecekte insanlarýn tamamý kanserden vs den ölmeyek sadece, elektrik çarpmasýndan ölücek . video da yeni bir icat daha gösterilmekte .. Toyota tarafýndan 2010 yýlýndan sonra satýþa sunulacakmýþ ,Bu ulaþým aracýna engelli kiþilerin ragbet göstereceðini tahmin edebiliyorum. - Yahoo! Canada Toolbar : Search from anywhere on the web and bookmark your favourite sites. Download it now! --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
document based database
are you guys aware of any document based database open source implementation in Python such as strokeDB for Ruby http://strokedb.com/ Thanks in advance -Bedros --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Multi-Table Inheritance and fixtures
In addition, it seems like my patch works for sqlite and mysql, but will fail under postgres. On Tue, May 20, 2008 at 3:09 PM, Ziling Zhao <[EMAIL PROTECTED]> wrote: > My fix was to simply set the parent's primary key attribute inside of th > child's data, which worked for all cases with the exception of when the > parent's primary key had the same name as the child's primary key. Upon the > loading of a model like that, i get the error "column name is not unique." > > I don't see why a parent model cannot have the same field name as a child > model. > > Is this a seperate bug? Maybe my approach towards solving the problem is > incorrect? > > Do I have a misunderstanding of OneToOneFields? E.g. they shouldn't share > pk field names (this makes sense to me)? > > > On Mon, May 19, 2008 at 2:52 PM, Ziling Zhao <[EMAIL PROTECTED]> wrote: > >> Well, the main problem with the parent table being saved independently of >> the children tables is that you could have a fixture that only had the >> children, seperate from the parents. So if you load that fixture, they would >> have no parents to associate to. >> >> I submitted a patch to my bug that seems to fix it in the deserialization >> part by setting the parents pk before converting it to an object. This >> should hopefully make it save/update correctly. >> >> >> On Sat, May 17, 2008 at 12:41 PM, AmanKow <[EMAIL PROTECTED]> wrote: >> >>> >>> On May 15, 6:15 pm, "Ziling Zhao" <[EMAIL PROTECTED]> wrote: >>> > So, are you suggesting that on fixture loading that parents should >>> *not* be >>> > saved? >>> > >>> > Would this possibly allow you to load fixtures that don't fit in your >>> model? >>> > E.g. children without parents? >>> >>> No, what I'm suggesting is that the parent table is being saved, >>> independently of the child tables. Later, the children are saved. I >>> am suggesting that on load, after the parent tables are loaded, the >>> children be loaded and only the child tables be touched. >>> >>> BTW, in your item below, parent_ptr is the primary key of the child, >>> foreign keyed to the parent, implicitly created by using multitable >>> inheritance. Thus MTI is just a special case of one to one where the >>> one to one field is also the pk. >>> >>> On May 15, 6:15 pm, "Ziling Zhao" <[EMAIL PROTECTED]> wrote: >>> > So, are you suggesting that on fixture loading that parents should >>> *not* be >>> > saved? >>> > >>> > Would this possibly allow you to load fixtures that don't fit in your >>> model? >>> > E.g. children without parents? >>> > >>> > >>> > >>> > On Sat, May 10, 2008 at 10:24 AM, AmanKow <[EMAIL PROTECTED]> wrote: >>> > >>> > > Above, I said: >>> > > > I notice that child instances have an undocumented save_base >>> method, >>> > > > which I assume is called from the child's save. I wonder if it >>> might >>> > > > not be useful to have some way (r.save(exclude_parent=True) or some >>> > > > such thing) in order to save the child record only. >>> > >>> > > But I didn't explain why I thought something like this might be >>> useful >>> > > for some types of processing and applicable to the loaddata issue. >>> > >>> > > For hooking up children to existing parents it would be simpler and >>> > > more efficient: >>> > > >>> p = Place(name="Lee's Tavern", address="Staten Island") >>> > > >>> p.save() >>> > > >>> r = Restaurant(serves_pizza=True, serves_hot_dogs=False, pk=p.pk >>> ) >>> > > >>> r.save(child_only=True) >>> > >>> > > You'd have to be a bit cautious here, as r will still have the >>> default >>> > > values for the parent fields. If you are going to continue to use r, >>> > > and access the parent fields in any way, the following would be >>> > > appropriate after the save: >>> > > >>> r = Restaurant.objects.get(pk=r.pk) >>> > >>> > > If indeed there is some sort of transactional issue in loaddata, >>> > > always specifying that only the child be saved (it wouldn't hurt to >>> > > specify it everywhere loaddata saves as it would be ignored where it >>> > > wasn't pertinent) might just be the fix. >>> > >>> > > Wayne >>> > >>> > -- >>> > ~Ziling Zhao >>> >>> >>> >> >> >> -- >> ~Ziling Zhao >> > > > > -- > ~Ziling Zhao > -- ~Ziling Zhao --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: document based database
bedros said the following: > are you guys aware of any document based database open source > implementation in Python such as strokeDB for Ruby This question does not belong on this list - this list is for the discussion of the development of django itself, not for other questions. -- Collin Grady The nation that controls magnetism controls the universe. -- Chester Gould/Dick Tracy --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: document based database
Perhaps bedros meant to ask if anyone is working on support in Django for any "document based" databases. strokeDB looks (to my untrained eye) similar to CouchDB. You'll find plenty to read if you do a search for "couchdb django". -- Daryl On Tue, May 20, 2008 at 4:06 PM, Collin Grady <[EMAIL PROTECTED]> wrote: > > bedros said the following: >> are you guys aware of any document based database open source >> implementation in Python such as strokeDB for Ruby > > This question does not belong on this list - this list is for the discussion > of > the development of django itself, not for other questions. > > -- > Collin Grady > > The nation that controls magnetism controls the universe. >-- Chester Gould/Dick Tracy > > > > --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: using oldforms.SelectMultipleField on a custom field nets a proper select list, but I am only ever given the last value selected from the form
solved this myself overriding the get_manipulator_new_data method to use getlist on newdata instead of get. On May 20, 2:01 pm, multigl <[EMAIL PROTECTED]> wrote: > Ostensibly, I'm using an app very similar to the django tagging app, > and the admin field used to be a text input that would do the > connecting magic for you, but unfortunately we have too many users > that find that complicated so I'm trying to turn it into a select > box. If I define the function get_manipulator_field_objs and return a > curried oldforms.SelectMultipleField I get a proper multiple select > box in the admin site, but selecting more than one response seems to > only hand a single value to my __set__ function. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Rethinking silent failures in templates
Has anyone considered using Python's 'warnings' module? It seems like
it might be the perfect fit for this problem.
For example, if the appropriate warn() calls were added to the
templating system, by default, problems would be sent to sys.stderr.
By setting up a warnings filter in (for e.g. in settings.py), we could
define which warnings ("errors") threw exceptions -- a fail loudly
solution. And finally, we could (I'm debating the usefulness of
this), create a 'showwarnings' tag which would format the current
warnings in the template.
This, at least to me, seems like it could solve most people's
problems.
Cheers,
-Curtis
On May 20, 3:55 pm, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> I can add newer patch if anyone interested.
>
> On Wed, May 21, 2008 at 2:54 AM, graham_king <[EMAIL PROTECTED]> wrote:
>
> > Making {{ myval }} fail loudy would break the admin app. Setting
> > TEMPLATE_STRING_IF_INVALID to anything other than '' also breaks it.
>
> > Here's an example:http://code.djangoproject.com/ticket/5532
> > This ticket has all the details:http://code.djangoproject.com/ticket/3579
>
> > Will this be fixed in newforms-admin?
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
