Re: Problem with history view in admin page
Richard,
> I don't know why a user should have .filter(object_id='1')
> fail, as that breaks the ORM abstraction. Maybe that's not what you're
> suggesting?
I am saying exactly what i am saying. So here's my example that does
the same thing in a java ORM
// Here's the model
@Entity
public class ClobTest {
@Id
@Type(type="text")
private String id ;
private String firstName ;
}
// here's the app
ClobTest c = EntityManager.find(hellojpa.ClobTest.class, "1");
// here's what happens
Exception in thread "main" javax.persistence.PersistenceException:
org.hibernate.exception.SQLGrammarException: could not load an entity:
[hellojpa.ClobTest#1]
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException
(AbstractEntityManagerImpl.java:637)
at org.hibernate.ejb.AbstractEntityManagerImpl.find
(AbstractEntityManagerImpl.java:202)
Caused by: com.ibm.db2.jcc.b.nm: DB2 SQL Error: SQLCODE=-401,
SQLSTATE=42818,
SQL0401N - The data types of the operands for the operation
"" are not compatible.
I am certain i would get the same exception if i used Oracle as the
DB. So i cant see why the Django Oracle Adapter should cover this.
Russ,
> With a different coat of paint, it might be more palatable. A name
> like ShortTextField presupposes the storage implementation, but tells
> you nothing about the appropriate usage. However, a different name -
> something like GenericKeyField tells you nothing about the storage,
> but does tell you when it might be appropriate to use it.
>
GenericKeyField - Its hard for me to see that a end-user would not be
interested in the specific type of his column at the database
especially if its a key field.
thanks
Mario
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Feature Request: Reinteract
I really love this application Reinteract. Its an enhancement to Python Interactive Shell. And it would be lovely if I can use Reinteract with manage.py shell. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feature Request: Reinteract
Since this would obviously create a lot of external dependecies of Django package (X, GTK, reinteract). I'd prefer if you'd just create a reausable app, that would add ./manage.py reinteract command. Ales -- Ales Zoulek +420 604 332 515 Jabber: ales.zou...@gmail.com -- On Fri, Nov 27, 2009 at 1:07 PM, noel wrote: > I really love this application Reinteract. Its an enhancement to > Python Interactive Shell. And it would be lovely if I can use > Reinteract with manage.py shell. > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Composite Primary/Foreign Keys
Hello all. I'm new to the Django community, but I have an itch that needs scratching and some time off to scratch it. The itch, of course, is composite primary and foreign keys in Django. I've started to speak with David Cramer on the issue. Several months ago, he was pursuing a solution which he has documented here: http://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys. David no longer believes that he was taking the right approach, so before I begin any work on this, I wanted to check the pulse of the developer community on the matter. Hopefully we can start a discussion to determine what the right approach is, and I can get to work implementing it. With a solid plan in place, perhaps others will want to join the cause too. The goal is to create a solution that will be worth introducing to the core Django distribution. So, if you have a moment, let's get things started here. It is understood that not everyone *needs* composite primary and foreign keys, but this is something that plenty of people do need, and it is in the interest of making the Django model layer more complete. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feature Request: Reinteract
On Nov 27, 10:07 pm, noel wrote: > I really love this application Reinteract. Its an enhancement to > Python Interactive Shell. And it would be lovely if I can use > Reinteract with manage.py shell. Have a look at bpython. I have a command set up where I can run ./manage.py bshell And I get a bpython shell with all of the models already imported. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feature Request: Reinteract
On Fri, Nov 27, 2009 at 6:07 AM, noel wrote: > I really love this application Reinteract. Its an enhancement to > Python Interactive Shell. And it would be lovely if I can use > Reinteract with manage.py shell. Before submitting feature requests, please check the release cycle; Django 1.2's feature window is closed. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Composite Primary/Foreign Keys
On Sat, Nov 28, 2009 at 4:49 AM, slango wrote: > Hello all. I'm new to the Django community, but I have an itch that > needs scratching and some time off to scratch it. The itch, of course, > is composite primary and foreign keys in Django. > > I've started to speak with David Cramer on the issue. Several months > ago, he was pursuing a solution which he has documented here: > http://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys. David no > longer believes that he was taking the right approach, so before I > begin any work on this, I wanted to check the pulse of the developer > community on the matter. Hopefully we can start a discussion to > determine what the right approach is, and I can get to work > implementing it. With a solid plan in place, perhaps others will want > to join the cause too. The goal is to create a solution that will be > worth introducing to the core Django distribution. > > So, if you have a moment, let's get things started here. It is > understood that not everyone *needs* composite primary and foreign > keys, but this is something that plenty of people do need, and it is > in the interest of making the Django model layer more complete. This is a long-standing issue for Django (ticket #373), and yes, we would like to have a solution. From a brief look at the wiki, it appears that the known issues and design constraints are well documented. However - with that said, we're currently about 1 month out from the deadline for adding new features to Django 1.2. The features that are scheduled for that release were chosen back in October, following several months of discussion and design plans. The core team is currently focussed on developing the features that we want in 1.2. As a result, you may find it difficult to get design feedback (or contributions) from those in the core team. I don't want to discourage you from working on this - if this is your itch, please do scratch it. I just want to let you know why you may not get the design feedback you need or want. On a positive note, If you want to consider this as a problem for the 1.3 timeframe, working through the issues now means that you will be able to present a solid design, and possibly even an implementation when the feature selection phase for 1.3 comes around. Working implementations always attract positive attention during the early phases. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Problem with history view in admin page
On Fri, Nov 27, 2009 at 4:21 PM, Mario Briggs wrote: > Russ, > >> With a different coat of paint, it might be more palatable. A name >> like ShortTextField presupposes the storage implementation, but tells >> you nothing about the appropriate usage. However, a different name - >> something like GenericKeyField tells you nothing about the storage, >> but does tell you when it might be appropriate to use it. >> > > GenericKeyField - Its hard for me to see that a end-user would not be > interested in the specific type of his column at the database > especially if its a key field. Depends on the focus of the developer. DB-focussed developers or developers looking to optimize query performance might care about the underlying storage. However, developers working at a higher level just want their data to be stored. The exact database type is irrelevant as long as queries using that field work in reasonable time. Django currently uses a TextField is currently storing a string-serialized form of the key of an arbitrary object. What is being stored in any given row can be determined by looking at the content_type of the row (or rather, the primary key type of the model that the content type refers to). It is used to create log entries that point at arbitrary objects in the database. From a pure DBA, third-normal-form perspective, it isn't an especially efficient data structure - but it *works* for the situation in which it used. At the end of the day, that's what really matters. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
