Greetings,
I'd like to ask, why Django ORM has no concept of Identity Map? It is
strange for me that if I call get() five times I will get five object
instances, instead of five references to a single instance.
Was it a design decision? I'm unable to find any discussions of this.
Hi,
Iam new to this community. I would like to know more about the django
ORM(i.e its internal workings). Can someone provide some good links
for this?
Goutham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"D
probably too hard for me to implement in even near commit-
quality.
These features would naturally make the ORM more powerful, but I see
some objections to these features:
1. They will make the already complex ORM even more complex. This
will result in new bugs and it will be harder to add new feat
is a big package and contains lots of modules, I found
it very difficult to understand the changes in the pull requests.
Do you know any good resource about the internal structure of the django
ORM? a blog post perhaps, anything to help me get started on the ORM
internals.
--
You received
Hi,
Given the small number of Django ORM maintainers, making the ORM standalone
will, among other things, increase the adoption of Django and bring in new
maintainers.
An ORM inspired by Django ORM with over 3000+ stars:
https://github.com/tortoise/tortoise-orm
--
You received this
nal safety
from the system if implemented improperly.
Anyone have any experience with this sort of setup under Django?
- Ben
On 2/2/07, Sergey Kirillov <[EMAIL PROTECTED]> wrote:
>
> Greetings,
>
> I'd like to ask, why Django ORM has no concept of Identity Map? It is
&g
ne have any experience with this sort of setup under Django?
>
> - Ben
>
>
> On 2/2/07, Sergey Kirillov <[EMAIL PROTECTED]> wrote:
> >
> > Greetings,
> >
> > I'd like to ask, why Django ORM has no concept of Identity Map? It is
> > strange for
On Nov 23, 8:18 am, Goutham DL <[EMAIL PROTECTED]> wrote:
> Hi,
> Iam new to this community. I would like to know more about the django
> ORM(i.e its internal workings). Can someone provide some good links
> for this?
Hi Goutham,
If you're new to the community,
I have downloaded the source code and gone through the official
documentation :).Iam more interested in how django does the mapping
from the code to SQL.
Goutham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dja
On 11/22/07, Goutham DL <[EMAIL PROTECTED]> wrote:
> Iam new to this community. I would like to know more about the django
> ORM(i.e its internal workings). Can someone provide some good links
> for this?
http://code.djangoproject.com/wiki/DevModelCreation
--
"Bureau
dy with more ORM knowledge than I have. The ModelAnnotation
> idea is probably too hard for me to implement in even near commit-
> quality.
>
> These features would naturally make the ORM more powerful, but I see
> some objections to these features:
> 1. They will make the already com
Hi Mahdi,
I would suggest reading the code and test code in the tests/ directory for
the ORM.
There might also be some videos from Django Under The Hood conferences,
found some here:
https://www.google.com/search?q=Django+Under+The+Hood+orm&tbm=vid
Best
--
You received this message because yo
Great, thanks
On Monday, May 13, 2019 at 1:17:08 PM UTC+4:30, J. Pic wrote:
>
> Hi Mahdi,
>
> I would suggest reading the code and test code in the tests/ directory for
> the ORM.
>
> There might also be some videos from Django Under The Hood conferences,
> found some here:
>
> https://www.googl
Yes there isn't much documented on the ORM internals, but there are other
resources. The DUTH videos are a great start and inspired me to get started
contributing to Django. Specifically:
- https://www.youtube.com/watch?v=CGF-0csOjPw
- https://www.youtube.com/watch?v=-4jhPRfCRSM
- https:/
Hello,
I would suggest https://www.youtube.com/watch?v=bgV39DlmZ2U if you'd like
to understand how the ORM is structured in layers.
--
Aymeric.
Le lun. 13 mai 2019 à 12:16, Adam Johnson a écrit :
> Yes there isn't much documented on the ORM internals, but there are other
> resources. The DUTH
I tend to believe the opposite is true. Django was/is a successor in its
field, because it offers an "out-of-the-box" or "batteries included"
experience. Subsequently parts were shaped as needed for that bigger
picture, e.g. the ORM became what it is today.
Does anyone still remember django ve
I second Jörg about better maintainability with tighter integrations.
However, for the fun of stirring the pot, what's the opinion on letting
Django define an API for the ORM and letting a library deal with the
DB-specific implementation that generates the SQL for query? Django could
have a li
I think we already have this no?
See https://docs.djangoproject.com/en/4.1/ref/databases/#s-third-party-notes
for a list of 3rd party DB backends.
On Tue, 13 Dec 2022 at 10:31, Vasanth Mohan wrote:
> I second Jörg about better maintainability with tighter integrations.
>
> However, for the fun
27;Bob'
Factory has several helper functions for lookups which aren't related to any
Python operators directly:
>>> Q.user.name.icontains('Bob')
And helper to get query path as string, which requred by order_by or
select_related queryset methods:
>>&
Hello,
I have question about type of design patterns using in Django ORM. It
is: Table Data Gateway, Row Data Gateway, Active Record or Data
Mapper? .. Personally I think that it's mix of Row Data Gateway and
Data Mapper, but I want to ask You guys for sure :-)
Thanks, regards,
P.R.
--
Hi all,
Have django developers planned the integration of new model fields
capable to store multidimensional data ? If it's not the case, how can
I submit this implementation request ?
By implementing this kind of basic types, I think it could be a way
for the Django project to reach the scientif
t; Q
>
>
> >>> Q.user.profile
>
>
> >>> Q(user__name='Bob')
>
>
> It overrides operators, so comparing factory with value returns a related Q
> object:
>
> >>> Q.user.name == 'Bob'
>
>
> Factory has several helper
a single argument only, very inconvenient
>> when
>> necessary to filter objects by range.
>>
>> I was thinking a lot trying to solve those issues, keeping in mind Django
>> approaches. Finally I came up with solution to extend Q objects with dot
>> expression
>>>
> >> >>>
> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday) \
> >> .order_by('user__profile__last_login_date')
> >>
> >> We can't keep user__profile_login_date as a variable as in the first
> p
ally if we have fields with
>> >> underscores.
>> >> It's really easy to make a mistake by missing one:
>> >>
>> >> >>>
>> >> >>>
>> GameSession.objects.filter(user_profile__last_login_date__gte=yesterday)
>> >
5 23:18:26 UTC+10, Alexey Zankevich wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> This topic is related to the current ORM query syntax with
>>> >> underscores.
>>> >> There are lots of arguing related to it, a
ed above. Then we can consider how all these
> >>> > things
> >>> > might work together, and clearly document why we've gone one way and
> >>> > not
> >>> > another. Obviously, alternatives can exist outside of core where the
> &g
e where the
> >>> > API is
> >>> > available.
> >>> >
> >>> > I'll be happy to work as the shepherd if needed. But I'd also like
> some
> >>> > input from Loic and Anssi especially, as well as others in the core
&
> > I think it may look better with F objects, considering they are
>> Field
>> >>> > references, and since the Lookups (Equal/GTE) parts accept F
>> >>> > expressions
>> >>> > anyway. I'm not too concerned about this particular d
gt; > (expressions/callable transforms) as well as the dot field reference
> >>> > notation you've proposed above. Then we can consider how all these
> >>> > things
> >>> > might work together, and clearly document why we've gone one way and
> >>>
meSession.objects.filter(Equal(Date(F.user.profile.last_login),
>> >>> > datetime.now().date))
>> >>> > GameSession.objects.filter(E(F.user.profile.last_login).date() ==
>> >>> > datetime.now().date)
>> >>> >
>&g
;).collate('fi') == 'Article1')
>>> >>> >
>>> >>> > Both of these approaches still suffer from "the string problem"
>>> that
>>> >>> > you're
>>> >>> >
ter syntax as a whole
> >>> > (expressions/callable transforms) as well as the dot field reference
> >>> > notation you've proposed above. Then we can consider how all these
> >>> > things
> >>> > might work together, and clearly docume
e right way to go here but I wonder if we should
> >>> > expand
> >>> > the scope to include alternative filter syntax as a whole
> >>> > (expressions/callable transforms) as well as the dot field reference
> >>> > notation you've propo
anyway. I'm not too concerned about this particular detail though.
> >>> >
> >>> > A DEP is probably the right way to go here but I wonder if we should
> >>> > expand
> >>> > the scope to include alternative filter syntax as a whole
gt; > I think it may look better with F objects, considering they are Field
> >>> > references, and since the Lookups (Equal/GTE) parts accept F
> >>> > expressions
> >>> > anyway. I'm not too concerned about this particular detail though.
> >>>
Hi Josh,
As https://github.com/django/django/pull/5090 pull request merged into
master, I wanted to extend django-orm-sugar library with some
functionality, related to passing transforms or lookup objects. Currently
it's not clear to me how lookups or transforms can be used in that way
gt; Q.user.profile
>
>
> >>> Q(user__name='Bob')
>
>
> It overrides operators, so comparing factory with value returns a related Q
> object:
>
> >>> Q.user.name == 'Bob'
>
>
> Factory has several helper functions for lookups which aren't related to
> any
> P
gt; >>> GameSession.objecs.filter(Q.user.profile.last_login_date >= yesterday)
>>
>> Q is a factory instance for old-style Q objects. Accessing attribute by
>> dot
>> returns a child factory, calling factory will instantiate old-style Q
>> object.
>&
gt;
>>> I was thinking a lot trying to solve those issues, keeping in mind Django
>>> approaches. Finally I came up with solution to extend Q objects with dot
>>> expression syntax:
>>>
>>> >>> GameSession.objecs.filter(Q.user.profile.last_
gt;>> remembered or
> >>> looked up in documentation. For example, "__gte" or "__lte" lookups
> tend
> >>> to be
> >>> confused with "ge" and "le" due to similarity to methods "__ge__" and
> >
> >>> We can't keep user__profile_login_date as a variable as in the first
>> part
>> >>> of the
>> >>> expression we use a keyword argument, meanwhile in the second part -
>> just
>> >>> a
>> >>> string. A
gt;> >>> though, it's not easy to say whether it should be "user_profile"
>>> >>> attribute or
>>> >>> user.profile foreign key.
>>> >>>
>>> >>> 2. Query strings can't be reused, thus the approach
> >>> >>> >>>
> >>> >>> >>>
> GameSession.objects.filter(user_profile__last_login_date__gte=yesterday)
> >>> >>>
> >>> >>> Not easy to catch missing underscore between user and profile, is
> it?
> >>>
;>>
>> >>> >>>
>> >>> >>> Pros:
>> >>> >>>
>> >>> >>> 1. The syntax is easy to understand
>> >>> >>> 2. Can be extended with custom transforms and lookups
>> >>> >>>
&g
underscores.
>>> >>> >>> There are lots of arguing related to it, anyway it has pros and
>>> cons.
>>> >>> >>>
>>> >>> >>> Let's take a concrete example of querying a model:
>>> >>>
e extended with custom transforms and lookups
>> >>> >>>
>> >>> >>> However, there are several cons:
>> >>> >>>
>> >>> >>> 1. Long strings is hard to read, especially if we have fields
>> On Sunday, August 16, 2015 at 4:18:26 PM UTC+3, Alexey Zankevich
>>> >>> >> wrote:
>>> >>> >>>
>>> >>> >>> Hi all,
>>> >>> >>>
>>> >>> >>> This topic is r
;>>>>>> object
>>>>>>>>> to Q object - filter will take already parsed lookup tree.
>>>>>>>>> Example:
>>>>>>>>>
>>>>>>>>> Q(user__name__lower__unaccent__icontains='Bob&
shall support explicit lookups/transforms
> >>>>>>>>> as
> >>>>>>>>> argument as well - it's a kind of logical step, as without Q
> >>>>>>>>> objects
> >>>>>>>>> it will
>
>>>>>>>> 1. Make Lookup.__init__ signature to support initialization with
>> >>>>>>>>> F
>> >>>>>>>>> objects
>> >>>>>>>>> or string path (e.g. GreaterThan(F('user__id'), 10) or
&
; On Wednesday, 30 September 2015 04:49:54 UTC+10, Alexey
> Zankevich
> >> >>>>>>>> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>> Here is a list of issues to solve to support exp
gt; >> >>>>>>>> Part 1 above can be started now if you have the time or
>> interest.
>> >> >>>>>>>> We
>> >> >>>>>>>> can
>> >> >>>>>&
>>>> Cheers
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On Wednesday, 30 September 2015 04:49:54 UTC+10, Alexey
> Zankevich
> >> >>>>>>>> wrote:
> >> >>>>>>&g
gt;>>>>>>> Cheers
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On Wednesday, 30 September 2015 04:49:54 UTC+10, Alexey
> Zankevich
> >> >>>>>>>> wrote:
> >> >
>> 3. Sounds like an OK idea, but I haven't looked into the
>>> >> >>>>>>>> details
>>> >> >>>>>>>> enough
>>> >> >>>>>>>> to
>>> >> >>>
ing transforms is now possible since they are just
> >>> >> >>>>>>>> Func
> >>> >> >>>>>>>> expressions.
> >>> >> >>>>>>>> Func(Func(Func('field_name'))) is no issue.
> >>> >
would say Django with NoSQL ORM support
could actually make it more popular compared to its rivals Ruby on Rails or
even Java for that reason.
Waiting for official Django ORM support for NoSql databases.
Thanks
--
You received this message because you are subscribed to the Google Groups
"Dj
https://pypi.org/project/django-cockroachdb/
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...
Hey all,
Just want to announce recent changes in Django ORM Sugar library, which
might be useful in future Django query syntax enhancement (if ever happens).
1. Now it supports indexes and slices:
>>> Q.data.owner.other_pets[0].name='Fishy'
Q(data__owner__other_pets__0__name=
+1 from me. I really like this approach to help making my queries more DRY.
I also like how lightweight the library is altogether. Well done!
For those looking for a direct link, here you
go: https://github.com/Nepherhotep/django-orm-sugar
On Thursday, October 6, 2016 at 1:04:56 PM UTC-4
h to help making my queries more DRY.
>
> I also like how lightweight the library is altogether. Well done!
>
>
> For those looking for a direct link, here you go:
> https://github.com/Nepherhotep/django-orm-sugar
>
>
>
> On Thursday, October 6, 2016 at 1:04:56 P
is approach to help making my queries more
>> DRY.
>>
>> I also like how lightweight the library is altogether. Well done!
>>
>>
>> For those looking for a direct link, here you go:
>> https://github.com/Nepherhotep/django-orm-sugar
>>
>>
>&
__created))
In []: -F.user.created
Out[]: OrderBy(FExpr(user__created), descending=True)
In []: F.text.iexact('...')
Out[]:
On Thursday, October 6, 2016 at 10:04:56 AM UTC-7, Alexey Zankevich wrote:
>
> Hey all,
>
> Just want to announce recent changes in Django ORM Sugar
rderBy(FExpr(user__created), descending=True)
>
> In []: F.text.iexact('...')
> Out[]:
>
>
>
>
> On Thursday, October 6, 2016 at 10:04:56 AM UTC-7, Alexey Zankevich wrote:
>>
>> Hey all,
>>
>> Just want to announce recent changes in Django ORM S
Hey all,
Please check a draft DEP related to external query language support by
Django ORM https://github.com/django/deps/pull/40.
Regards,
Alexey
On Wednesday, March 22, 2017 at 10:07:51 AM UTC+3, Asif Saifuddin wrote:
>
> Hi Aric,
>
> I checked your package. it's nice to
Hey all,
can we have some consensus on this?
Asif
On Saturday, April 1, 2017 at 12:55:27 PM UTC+6 Alexey Zankevich wrote:
> Hey all,
>
> Please check a draft DEP related to external query language support by
> Django ORM https://github.com/django/deps/pull/40.
>
> Regards,
I would not be for merging anything into Django at this time.
There are several libraries providing "enhanced" query syntax:
django-orm-sugar, django-model-values, and django-natural-query. None of
them seems to be particularly popular (<100 github stars, minimal PyPI
downloads), an
Hi Adam,
I agree with some of your points. however djngo orm query syntax is the
main pain point for anyone new to django orm. The reason those packages
are not widely used is because most people dont know about them and not
about this DEP. And most new users mainly end up learning built in
On Wed, Feb 24, 2010 at 12:20 AM, P.R. wrote:
> Hello,
>
> I have question about type of design patterns using in Django ORM. It
> is: Table Data Gateway, Row Data Gateway, Active Record or Data
> Mapper? .. Personally I think that it's mix of Row Data Gateway and
> Data Ma
On Wed, Feb 24, 2010 at 7:57 AM, Russell Keith-Magee wrote:
> On Wed, Feb 24, 2010 at 12:20 AM, P.R. wrote:
> > Hello,
> >
> > I have question about type of design patterns using in Django ORM. It
> > is: Table Data Gateway, Row Data Gateway, Active Record or Data
oSQL users waiting for an official
> ORM support from Django like me. I would say Django with NoSQL ORM support
> could actually make it more popular compared to its rivals Ruby on Rails or
> even Java for that reason.
>
> Waiting for official Django ORM support for NoSql databa
Hi all,
On Tue, 17 Dec 2013, Tom Evans wrote:
On Tue, Dec 17, 2013 at 3:35 PM, parisrocks
wrote:
Waiting for official Django ORM support for NoSql databases.
MongoDB (and the vast majority of NoSQL databases) are not relational
databases, they are document oriented databases, they store
Hi Chris,
On 17 déc. 2013, at 17:50, Chris Wilson wrote:
> There is no particular reason NOT to do it, unless one wants Django's ORM
> layer to remain fundamentally tied to SQL.
I don’t understand your sentence. To me it’s as if you were saying “there is no
particular reason NOT to relay emai
On Tue, Dec 17, 2013 at 4:50 PM, Chris Wilson wrote:
> Hi all,
>
>
> On Tue, 17 Dec 2013, Tom Evans wrote:
>
>> On Tue, Dec 17, 2013 at 3:35 PM, parisrocks
>> wrote:
>>>
>>> Waiting for official Django ORM support for NoSql databases.
>>
>
Hello
I think there is a difference between an ORM and an Document-Object
Mapper as
MongoEngine, I don't know if django ORM is designed to play a role
adapted to a Document-Object Mapper, if not you can always use apps to that
could be integrated to the django world and also a document m
On Tue, Dec 17, 2013 at 2:05 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 17 déc. 2013, at 19:53, Javier Guerra Giraldez
> wrote:
>
> > On Tue, Dec 17, 2013 at 12:16 PM, Aymeric Augustin
> > wrote:
> >> Django’s ORM is entirely designed to translate between an object
>
ect. So knowing what it takes to use the
django ORM to work with a NoSQL DB, I hope I can provide some useful
information.
There are a few issues that we run into, so you can see that they are not
fundamental problems.
1. Things you can do on a SQL system that you can't on NoSQL.
- The
at's
> so that we can add a "noSQL" module at some later date. We've also been
> aggressive about adding SQL-specific features (e.g., HAVING clauses, GROUP
> BY clauses) to the ORM API.
so, now i don't really know if Django ORM is appropriate for NoSQL or not.
On 17 déc. 2013, at 20:38, Karen Tracey wrote:
> https://groups.google.com/d/msg/django-developers/0IuJssTt8tc/TxdXQ2D0thcJ
Interesting. Now I remember reading that message last year. I have three
reactions.
First, Russell and I agree that the interest has faded. Currently, the best
option is
On 17 déc. 2013, at 19:53, Javier Guerra Giraldez wrote:
> On Tue, Dec 17, 2013 at 12:16 PM, Aymeric Augustin
> wrote:
>> Django’s ORM is entirely designed to translate between an object oriented
>> API and SQL. That’s what its name says. It achieves this through roughly
>> five layers that br
On Wed, Dec 18, 2013 at 4:41 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 17 déc. 2013, at 20:38, Karen Tracey wrote:
>
> https://groups.google.com/d/msg/django-developers/0IuJssTt8tc/TxdXQ2D0thcJ
>
>
> Interesting. Now I remember reading that message last year. I have t
On Tuesday, December 17, 2013 8:12:43 PM UTC-6, Russell Keith-Magee wrote:
>
>
> My claim is that complete abstraction of the data store shouldn't be the
> goal. What we should be aiming for is sufficient API compatibility to allow
> for two things:
>
> * ModelForms wrapping a model from a NoS
On Wed, Dec 18, 2013 at 12:18 PM, wrote:
>
> Wouldn't an easy (i.e. straightforward) solution be to add an Django "ODM"
> that mirrors the ORM wherever it makes sense? This sounds pretty close to
> your second solution, except choosing SQL vs NoSQL means users make a more
> explicit choice wheth
On Thu, Dec 19, 2013 at 1:18 AM, wrote:
>
>
> On Tuesday, December 17, 2013 8:12:43 PM UTC-6, Russell Keith-Magee wrote:
>>
>>
>> My claim is that complete abstraction of the data store shouldn't be the
>> goal. What we should be aiming for is sufficient API compatibility to allow
>> for two thing
On Thu, Dec 19, 2013 at 1:47 AM, Javier Guerra Giraldez
wrote:
> On Wed, Dec 18, 2013 at 12:18 PM,
> wrote:
> >
> > Wouldn't an easy (i.e. straightforward) solution be to add an Django
> "ODM"
> > that mirrors the ORM wherever it makes sense? This sounds pretty close
> to
> > your second soluti
This is the mailing list for the development of Django itself. Please use
django-users for messages like this.
On Monday, January 27, 2020 at 4:27:01 PM UTC-5, Charlotte Dillon wrote:
>
> https://pypi.org/project/django-cockroachdb/
>
--
You received this message because you are subscribed to t
My proposal is a database data dumper based on django ORM - It would
not produce SQL but python code that would insert the data. Something
like (example dump):
###
from os import environ
environ['DJANGO_SETTINGS_MODULE'] = 'settings'
from django.contrib.aut
I made a patch for Django to add QuerySet.fields(*fields,
**related_fields) and make possible to load only some from master and
related models fields. It allows to tune various object list queries
when we need only limited subset of all fields, improve general
performance and decrease database loa
On 1/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
My proposal is a database data dumper based on django ORM - It would
not produce SQL but python code that would insert the data. Something
like (example dump):
###
from os import environ
environ['DJANGO_SETT
I half-wrote something similar (1) to extract some data for an app.
It's very preliminary - you'll need to hand-edit the ordering of
relationships etc, but you can get a list of the various api
save/create commands which will recreate the data.
Hope it helps,
Simon
[1] http://simon.net.nz/artic
On 1/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
My proposal is a database data dumper based on django ORM - It would
not produce SQL but python code that would insert the data. Something
like (example dump):
You might want to check out the phase 3 patches associated with
http://simon.net.nz/articles/django-database-export-v1/ is nice :)
I was refering to something more than ju a way to make dumps - a
dumper which has an admin page where I could select what to dump and
other options.
--~--~-~--~~~---~--~~
You received this m
On Thu, 2008-02-14 at 03:50 -0800, Entropy Hacker wrote:
> I made a patch for Django to add QuerySet.fields(*fields,
> **related_fields) and make possible to load only some from master and
> related models fields. It allows to tune various object list queries
> when we need only limited subset of
> I made a patch for Django to add QuerySet.fields(*fields,
> **related_fields) and make possible to load only some from master and
> related models fields. It allows to tune various object list queries
> when we need only limited subset of all fields, improve general
> performance and decrease da
On 14 Feb, 17:26, Sebastian Noack <[EMAIL PROTECTED]>
wrote:
>
> Of course, this decreases database load, but IMHO it is better to use
> QuerySet.values if you want select just certain values from a model.
Often I need methods defined in models and isn't available at
dictionaries.
For example get
On Fri, 2008-02-15 at 01:54 -0800, Dima Dogadaylo wrote:
> On 14 Feb, 17:26, Sebastian Noack <[EMAIL PROTECTED]>
> wrote:
> >
> > Of course, this decreases database load, but IMHO it is better to use
> > QuerySet.values if you want select just certain values from a model.
>
> Often I need method
On Fri, 15 Feb 2008 01:54:24 -0800 (PST)
Dima Dogadaylo <[EMAIL PROTECTED]> wrote:
> > Of course, this decreases database load, but IMHO it is better to
> > use QuerySet.values if you want select just certain values from a
> > model.
>
> Often I need methods defined in models and isn't available
On Fri, 15 Feb 2008 21:30:23 +1100
Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> There's also the fairly pragmatic side-effect that if you are only
> pulling back a very few fields, there isn't really a lot your model
> methods are going to be able to do without loading more data, unless
> they
On 15 Feb, 12:30, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> When Adrian
> proposed that API, he realised that almost always you're going to be
> pulling back all of the fields or almost all of them. Once a database
> has read a row to access some of the data, accessing all of the data in
>
1 - 100 of 148 matches
Mail list logo
