Hi James.
> > Second, models.get_model(app_label, model_name) enforce that the
> > profile object must be a Model subclass and should be in
> > INSTALLED_APPS.
>
> I think this is worth living with -- the standard use case will be
> that it's a Django model class, and if it's not it becomes a nig
I'm against this, as it stops the developer thinking.
It also doesn't work on multi-site installations.
It also stops developers having the ability to use the cache at the
global granularity or to
use cache keys from other applications sometimes.
regards
Ian
On 04/04/2007, at 5:48 AM, Nowell
On 4/4/07, Max Derkachev <[EMAIL PROTECTED]> wrote:
> Well, User do nothing with the profile other then simply loading it in
> get_profile.
Except that 'get_profile' uses a Django database API lookup. Suppose
we remove that, though:
1. How do we know what sort of object the "profile" is?
2. How
I have summarized the problems I had with django's json serializer
here
http://wolfram.kriesing.de/blog/index.php/2007/json-serialization-for-django
i would be very interested if I might be doing something completely
wrong or if those are reall life problems other people have too. If so
I would b
On Apr 4, 2:09 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 4/4/07, Max Derkachev <[EMAIL PROTECTED]> wrote:
>
> > Well, User do nothing with the profile other then simply loading it in
> > get_profile.
>
> Except that 'get_profile' uses a Django database API lookup. Suppose
> we remove th
The code would be like
So, the code would be something like
def get_profile(self):
"""
Returns site-specific profile for this user. Raises
SiteProfileNotAvailable if this site does not allow profiles.
"""
if not hasattr(self, '_profile_cache'):
On 4/4/07, Wolfram Kriesing <[EMAIL PROTECTED]> wrote:
>
> I have summarized the problems I had with django's json serializer
> here
> http://wolfram.kriesing.de/blog/index.php/2007/json-serialization-for-django
> i would be very interested if I might be doing something completely
> wrong or if t
darn, it must have slipped into the spam, sorry.
thx for the reply
On 4/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 4/4/07, Wolfram Kriesing <[EMAIL PROTECTED]> wrote:
> >
> > I have summarized the problems I had with django's json serializer
> > here
> > http://wolfram.kriesing.
Hi all,
I've been hunting bug #3915, and I think I've found the cause, but I
can't see an obvious solution. AFAICT, the problem only exists with
Postgres, because it's the only backend that uses sequences for
primary key allocation.
Here's a sample Django session. MyModel is a some random model
This might be pretty simple to do, but I can't seem to figure it out.
How do I retrieve the names of column within a table, such is one
below?
class myTable(models.Model)
one = models.CharField()
two = models.CharField()
Thanks,
--~--~-~--~~~---~--~~
You rec
Hey Russ,
On Wed, 2007-04-04 at 22:07 +0800, Russell Keith-Magee wrote:
> Hi all,
>
> I've been hunting bug #3915, and I think I've found the cause, but I
> can't see an obvious solution. AFAICT, the problem only exists with
> Postgres, because it's the only backend that uses sequences for
> pri
On Wed, 2007-04-04 at 07:27 -0700, Moses Ting wrote:
> This might be pretty simple to do, but I can't seem to figure it out.
> How do I retrieve the names of column within a table, such is one
> below?
>
> class myTable(models.Model)
> one = models.CharField()
> two = models.CharField()
Use
On Wed, 2007-04-04 at 07:27 -0700, Moses Ting wrote:
> This might be pretty simple to do, but I can't seem to figure it out.
> How do I retrieve the names of column within a table, such is one
> below?
In future, too, please direct these sorts of questions to django-users.
This list is for posts
On 4/4/07, Max Derkachev <[EMAIL PROTECTED]> wrote:
> That's not a problem. The API lookup can be easily emulated in custom
> class. The problem is that it tries to load the profile from django's
> internal models cache, and that can't be easily emulated. One needs to
> cheat django the hard way f
On 4/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I can work around this problem in a messy way in the deserializer by
> manually resetting the sequence to the largest PK value that was found
> during deserialization, but that isn't really clean, and doesn't fix
> the manual allocation p
On 4/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
...
> AFAICT, the problem only exists with
> Postgres, because it's the only backend that uses sequences for
> primary key allocation.
Oracle does too, if/when that branch lands.
--~--~-~--~~~---~--~~
You r
On Apr 2, 8:31 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 4/2/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> > On 4/1/07, James Bennett <[EMAIL PROTECTED]> wrote:
> > > Anyone have strong opinions against this before I whip up a patch?
>
> > +1 on adding "headers", -1 on adding
I wrote a reply, but it seems that Google lost it.
In short.
We can not subclass User or provide custom User-like class, and use it
without loosing functionality that depends on contrib.auth stuff. The
profile thing is the only officially proposed method for extending the
User model at this time.
On 4/4/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> All we can do is set the
> next sequence value to one greater than the largest existing pk value;
> there's no way to tell the automatic sequence to skip a particular value
> in PostgreSQL.
That's the solution I was hinting at without t
On 4/4/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On 4/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> ...
> > AFAICT, the problem only exists with
> > Postgres, because it's the only backend that uses sequences for
> > primary key allocation.
>
> Oracle does too, if/when that branch l
If this does get reasonably fixed, can this be applied to 0.96.1?
This is a bug-fix and the bug it fixes makes testing with fixtures
(one of the 0.96's tauted features) a pain.
-Mike Axiak
On Apr 4, 8:42 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 4/4/07, Jeremy Dunck <[EMAIL PROTE
21 matches
Mail list logo
