Re: Bump again - #2333/Django testing framework
On 8/26/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: My only critique would be that there's no documentation of how to useyour stuff to test Django apps. Even a quick howto would be super-useful. I'm sure I'll get around to writing one sooner or later, butif you've got the time that would rock. I was planning to write some documentation. I just didn't want to sit down and write a whole spiel and then find out that it all had to change after feedback from Adrian or yourself. So, I'd say that -- unless Adrian thinks otherwise -- you're good to go.Cheers. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: SOC Integration Plan/Policy/Timeline
I think I'll play with full-text indexing and maybe with Row Level Permissions in my wiki :) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Support for Native XML Database (NXD)
http://www.xml.com/pub/a/2001/10/24/follow-yr-nose.html?page=2 "Relational databases are particularly good for storing highly structured information, and not particularly good at managing semi-structured data. Semi-structured data is data that has some structure, but is not rigidly structured. An example of semi-structured data is a health record. For example, one patient might have a list of vaccinations, another might have height and weight, another might have a list of operations they have had. Other examples of semi-structured data are legal documents and genealogical records... Semi-structured data is difficult to store in a relational database because it means you either have many different tables (which means many joins and slow retrieval time) or a single table with many null columns. Semi-structured data is very easy to store as XML and is a good fit for a native XML database." I think that would be a big step if we could implement a NXD in Django, but I don't speak of substitute a RDBMS by NXD else of using NXD when it was really necessary. http://www.xml.com/pub/a/2001/10/31/nativexmldb.html Some potential application areas include * Corporate information portals * Catalog data * Manufacturing parts databases * Medical information storage * Document management systems * B2B transaction logs * Personalization databases and of course for the mail addresses. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Support for Native XML Database (NXD)
http://www.xml.com/pub/a/2001/10/24/follow-yr-nose.html?page=2 "Relational databases are particularly good for storing highly structured information, and not particularly good at managing semi-structured data. Semi-structured data is data that has some structure, but is not rigidly structured. An example of semi-structured data is a health record. For example, one patient might have a list of vaccinations, another might have height and weight, another might have a list of operations they have had. Other examples of semi-structured data are legal documents and genealogical records... Semi-structured data is difficult to store in a relational database because it means you either have many different tables (which means many joins and slow retrieval time) or a single table with many null columns. Semi-structured data is very easy to store as XML and is a good fit for a native XML database." I think that would be a big step if we could implement a NXD in Django, but I don't speak of substitute a RDBMS by NXD else of using NXD when it was really necessary. http://www.xml.com/pub/a/2001/10/31/nativexmldb.html Some potential application areas include * Corporate information portals * Catalog data * Manufacturing parts databases * Medical information storage * Document management systems * B2B transaction logs * Personalization databases and of course for the mail addresses. --~--~-~--~~~---~--~~ 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: Support for Native XML Database (NXD)
GinTon wrote: > I think that would be a big step if we could implement a NXD in Django, > but I don't speak of substitute a RDBMS by NXD else of using NXD when > it was really necessary. I think you'd first have to go 'up' a layer, and define an API onto semi-structured data, and then you could plug in some other database system. For example Zope's ZODB, or an NXD storing as XML. In fact if you use ZODB in Django you could also use Zope Page Templates and then No, I wont go there. I can't see any reason why you cant use an object database in Django, its just that the admin interface to it won't work like the current admin interface. Zope has a nice management interface to its object database - you could use that for management and then Django for everything else (URL mapping, forms, templates) by importing zodb... But what a beast we would have created... Its ALIVE!!! The Frankenwebinterface... So in short, Django is just python, do "import myFaveNXD" and code away if you want. Barry --~--~-~--~~~---~--~~ 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: Modular Django
> That's cool -- mind posting your code somewhere? http://cheeseshop.python.org/pypi/urlrelay/ CheeseShop and setuptools makes installation of even my trivial modules on my webhost and other places I need it convienient. >> 1) Develop a loosely coupled module that acts like the "usual" Python >> module >> 2) Develop a piece of WSGI middleware >> 3) Something else > > Personally, I would lean towards #1, but since Django modularity > isn't an itch I have, chances are someone with a more pressing need > will beat me to it. At least in the case of urlresolvers, the existing loose coupling of Django's modules following the approach of #1 to some extent made #2 relatively painless. That may be as good a way to go it as any. --~--~-~--~~~---~--~~ 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: Support for Native XML Database (NXD)
[EMAIL PROTECTED] wrote: > I can't see any reason why you cant use an object database in Django, > its just that the admin interface to it won't work like the current > admin interface. As you can read in the down link I am trying to implementig the free specifications of OASIS (xNAL, xPIL). They are a set of XML specifications for defining and managing Customer (also called "Party") information/profile (including customer/party relationships) that are truly open, vendor neutral, application independent and importantly "Global". Including the capability of handling about 36+ customer name formats and addresses of 241+ countries with about 130+ Address formats and represented in 5,000+ languages. http://groups.google.com/group/django-ecommerce/browse_thread/thread/cdf513c26cc78f7e --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Sug] Reversed url lookup: would be nice to return more than the resulting url.
Apparently in the current trunk reversed urllookup is sort of working. After toying with it a little bit I found an issue: The main method, reverse, only returns the resulting matched url. Not the rule (the regex and extra arguments) it matched. There is no reliable way of knowing which (kw)args got matched and which ones have been ignored. I needed to know to pass the unmatched arguments as querystring. Moreover it would be nice to know what arguments have been passed to the rule. For example adding the parameter https:True would then allow me to build the url as https. In django-users i posted a little tag making available url_for in your templates. --~--~-~--~~~---~--~~ 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: Support for Native XML Database (NXD)
I´ve looked into some Oasis-specs (UBL) a while ago, and while i can see some sense in applying detailed standards in specific B2B-procurement areas, I´m more skeptical, whether these complex approaches will really scale beyond those markets. Adam Bosworth, VP, Engineering at Google stated in his keynote at the MySQL Users Conference 2005 the lesson of the web: "True power comes from decentralization and standards that are open, easy to understand and easy to implement" I would highly encourage you to listen to his presentation and have a look at his slides: http://www.itconversations.com/shows/detail571.html http://www.sdforum.org/images/events/presentations/Google_AdamBosworth.ppt In this talk he elaborates on his initial vision to achieve a Web of Data through XML, explains why it didn´t happen in the first place and proposes how it could still happen: with simple sloppy highly scalable protocols that share single common formats. That presentation had been given more than a year ago and since then Google had been hard at work to publish actual working code that is based on Bosworth´s vision. http://code.google.com/apis/gdata/ http://code.google.com/apis/base/ And suddenly it makes a lot of sense, why Google is putting all these efforts into their api architecture: http://radar.oreilly.com/archives/2006/07/a_week_in_the_valley_gdata.html So in the end the flavor of XML you will tend to choose probably will relate to the specific context, the needs of involved parties and the requirements for scalability. But I wouldn´t underestimate the power of simplicity. --~--~-~--~~~---~--~~ 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: Incorrect error message in template.loader.filesystem.py
Hi Adrian, I was not really using get_template_sources directly but it was used in some of the code I was debugging (o; Thanks for the fix, Martin --~--~-~--~~~---~--~~ 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: BigIntegerField
Felix Ingram wrote: > On 8/22/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > > > I'd like an integer field larger than postgresql's integer (2^31). > > > > Any interest in a patch for BigIntegerField? > > Matt Croydon submitted a patch a while ago: > http://code.djangoproject.com/ticket/399 > > It might need a bump. > > Felix Coincidentally, I was working on this issue today, as I also need the BigIntegerField functionality. Matt Croydon patch is now quite dated for the existing codebase. I have updated ticket #399 with the new patch. It is called bigint_patch_06aug06.txt. Since I am most familiar with MySQL, I modified the backend code for MySQL. The changes for Oracle, postgres, sqlite, etc. should be minimal. I have done some simple tests. Please take it out for a spin. Gopal --~--~-~--~~~---~--~~ 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: [Fw]The Python Web Framework
James Bennett wrote: > On 8/22/06, Karl Guertin <[EMAIL PROTECTED]> wrote: > > http://www.sqlalchemy.org/docs/adv_datamapping.myt > > Some of these examples deal with rather exotic use cases that, I > think, are close to the edge of what ORM can reasonably do before the > abstraction starts leaking. > > The "map multiple tables to an object", for example, really feels like > something that'd be better handled by a view at the database level. Yes, a lot of things would be better handled at the database level, e.g., inheritance, views, more advanced validation, but it would break database independence. I guess there's more than a few people running MySQL/PostgreSQL as their production and development database, but SQLite (:memory:) as their testing database. > It's something to think about though; if you've got ideas for concrete > implementations that would satisfy relatively common use cases, please > do submit tickets for them. It's unfortunately beyond me. These things are presumably quite hard to get right, and that's why I use a framework. What's a bit dangerous is that I do feel a bit let down if the framework oversold itself in this respect when I 3 months down-the-road discover it couldn't do what I need (thus the rants about "it's all marketing"). To me, what Django got right is a coherent set of core components that work well and feel right together, and that's extremely important. They're not individually "best of breed", but they don't feel as frankensteinish together as some of the other frameworks' components. This is also, btw, what Ruby on Rails got right initially; over time the components improved, and they're now really good. All we need is involvement of experts for each of the tricky components :( I'll add another thing to the wish-list for the framework: database schema/data migration. Rgds, Bjorn --~--~-~--~~~---~--~~ 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: Re: [Fw]The Python Web Framework
On 8/26/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote: > Yes, a lot of things would be better handled at the database level, > e.g., inheritance, views, more advanced validation, but it would break > database independence. Inheritance makes sense in the ORM, because we want to be able to map inheritance of code classes to some form of relations in database tables. Mapping a single code class to multiple tables, though, is something that can go either way; from an efficiency standpoint, it's probably best done via a view at the database level, but if someone can point to a common enough use case I (personally) would start seeing the argument for supporting it at the framework level getting stronger. > I'll add another thing to the wish-list for the framework: database > schema/data migration. Help us test it: http://code.djangoproject.com/browser/django/branches/schema-evolution -- "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 -~--~~~~--~~--~--~---
OneToOneField and non-integer primary keys
Someone in IRC tonight was running into the problem described in ticket #343 tonight, and after a quick test I can verify it's still happening in trunk. I'm blacklisted in Trac right now (Tom's looking into it), so I'll post some thoughts here. The root of the problem is that OneToOneField inherits from IntegerField, so regardless of the actual field type of the related model's primary key, the OneToOne wants to be an integer and that ends up breaking things. There are two solutions I can think of for this: 1. Re-implement OneToOneField to inherit directly from Field instead (foreign keys do this, which is why I assume they don't run into the same problem). 2. Re-implement OneToOneField to inherit from ForeignKeyField. This makes more sense to me, personally, because it ends up being a foreign key in the database anyway. At first glance I think this would also be less work, but I haven't gotten into the code deeply enough to be certain. Anyone have a strong preference either way before I start working on patches? -- "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: [Fw]The Python Web Framework
James Bennett wrote: > On 8/26/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote: >> Yes, a lot of things would be better handled at the database level, >> e.g., inheritance, views, more advanced validation, but it would break >> database independence. > What would be really useful for django is: 1. Full and native support within the API for calling server side procedures, including returning sets 2. Support for deferrable keys 3. Support for composite indexes (preferably through a try/except model versus the select/true model) I have spent a lot of money working *around* django instead of with it. Don't get me wrong, we love django and it is great for 75% of everything out there but highly advanced database applications that require the other 25% Django maks it a pain in the arse. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.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 -~--~~~~--~~--~--~---
