Re: Query Refactor Final Status Update
Hi Alex, On Aug 21, 9:01 am, Alex Gaynor wrote: > However the largest open question is what of this work > should be merged into trunk, and what should live external. My > recommendation would be for any changes in Django itself to be merged, > including the new form fields, but for the MongoDB backend (and, > indeed, any future backends) to live external to Django, until such a > time as it obtains a user base anywhere approaching our current > backends, as well as a more individuals dedicated to maintaining it. Leaving the backend as a separate project makes sense. Regarding merging into Django: There are still a few open design issues: http://github.com/alex/django/blob/query-refactor/MERGE_CONSIDERATIONS.txt IMHO, at least the AutoField issue should be dealt with before merging into trunk, so the API for end-users is finished. Ideally, also upsert support would be added (it's very easy to do, anyway). At some point we'll also need a solution for delegating the deletion of related objects to the backend. This is needed at least for App Engine, probably also for HBase, and maybe for some other DBs with transaction support. Bye, Waldemar Kornewald -- 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: Query Refactor Final Status Update
Hi Alex, I agree about leaving the backend outside django too (IMHO, all backends should live outside django). Is there any link that points to the apps you used for tests and to the mongodb backend? As you might know, We've been working on a django_mongodb_engine that uses django-nonrel and djangotoolbox. It currently works well (we use it in production) and it would be great to integrate part of our work with yours if it is possible. As Waldemar said, the AutoField issue should be dealt before merging and I would suggest to leave the non standard AutoField definition to the backends and then adding an attr into the Meta class that specifies the class that should be used for AutoFields in case it isn't the standard one. For example: class Mymongo(models.Model): . class Meta: auto_field_class = MyMongodbAutofieldClass IMHO, this could be an easy and fast way to deal with the AutoField issue. On 22 ago, 11:18, Waldemar Kornewald wrote: > > At some point we'll also need a solution for delegating the deletion > of related objects to the backend. This is needed at least for App > Engine, probably also for HBase, and maybe for some other DBs with > transaction support. +1 Agree... Cheers Flavio Percoco Premoli -- 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.
[gsoc/app-loading] final status report
Hey there,
the GSOC is over and I wanted to give you all a final status report.
The AppCache was refactored and now creates app instances instead of just
loading models. An app is either an instance of django.core.apps.App or a
custom class. This depends on the entry in the INSTALLED_APPS setting. Here's
an example:
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.sites',
'myproject.poll.MyPollApp',
)
With this setting, three instances will be created. Two instances of the
django.core.apps.App class and one MyPollApp instance. The MyPollApp class
could look like this:
from django.core.apps import App
from django.utils.translation import ugettext as _
class MyPollApp(App):
def __init__(self, name):
super(MyPollApp, self).__init__(name)
self.verbose_name = _('Poll')
self.db_prefix = 'foo'
The first thing to note is the verbose_name attribute, which allows for a more
descriptive name of the app. Currently the app name is the app_label, so "auth"
would be used for "django.contrib.auth". However, something like
"Authentication" would fit better from a UI perspective. The name can be passed
to the ugettext function and translated in the projects .po file on the next
run of makemessages. I modified the admin to use the verbose_name instead of
the app_label.
The db_prefix attribute allows the app to specify the prefix used when the
tables are created in the database. If the above app would have a "Poll" model,
it would be created as "foo_poll" instead of "poll_poll".
There many more attributes than can be implemented like a fixture prefix or
admin permission prefix. The models app label is currently used for far too
many things.
One thing I noticed was that a lot of code in Django itself or 3rd party apps
iterates over the installed apps and imports them. This won't work anymore as
an app can now also be a path to a class, so the import will raise an exception.
The ideal solution would be to change the code to iterate over the app
instances instead of the INSTALLED_APPS setting, but this might be a little bit
too much to ask. So, there's now an "installed_apps" attribute on the AppCache
that is a normalized version of the settings.INSTALLED_APPS variable (with
classnames removed). This makes the migration easier as this code:
for app in settings.INSTALLED_APPS:
import_module(app)
simply needs to be changed to this:
for app in cache.installed_apps:
import_module(app)
Applications with the same app label still cannot be created. The problem is
backwards compatibility, as the methods of the AppCache (get_model/get_app
etc.) all take the app_label as an argument. If, for example, there would be
two "auth" app instances (e.g. django.contrib.auth
and myproject.auth) calling get_model('auth', ...) the function must still
return the first one. I don't see migration path from app label to full path
without breaking bc.
Nevertheless, things have improved a little here. Previously, loading two apps
with the same app label would assign the models of the second app to the first
app, leaving the user with one auth app that mixed together the models from
both apps. That won't happen anymore. Now there will be only one auth app, and
the second will not be loaded. Hopefully this will clear up some confusion.
Overall, I'm happy with the result. Working on this project was a great
experience for me. I plan to continue my work on this branch after gsoc. Jannis
Leidel was a fantastic mentor, always available and really helpful.
I have the next 2 weeks filled up with exams but I'll be in Portland for
DjangoCon in early September. I'm always open to feedback and planning on
attending the sprints to do some further work. So until then...
Regards,
Arthur
--
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: Query Refactor Final Status Update
Hey Flavio, On Sun, Aug 22, 2010 at 12:40 PM, FlaPer87 wrote: > Hi Alex, > > I agree about leaving the backend outside django too (IMHO, all > backends should live outside django). Is there any link that points to > the apps you used for tests and to the mongodb backend? > > As you might know, We've been working on a django_mongodb_engine that > uses django-nonrel and djangotoolbox. It currently works well (we use > it in production) and it would be great to integrate part of our work > with yours if it is possible. Yes, you should definitely do that. I already told Alex that the MongoDB backend has to merge filters sometimes. For example, I think Alex' MongoDB backend won't work with filter(x__gt=3, x__lt=5), please correct me if I'm wrong. I implemented support for merging filters in django_mongodb_engine, so you could reuse at least that. Apart from that I just remembered a little issue in the current ORM: is_null queries on ForeignKey generate code which requires a JOIN. This inefficiency should probably also be fixed before 1.3 stable gets out. There is an issue for this, already: http://code.djangoproject.com/ticket/10790 > As Waldemar said, the AutoField issue should be dealt before merging > and I would suggest to leave the non standard AutoField definition to > the backends and then adding an attr into the Meta class that > specifies the class that should be used for AutoFields in case it > isn't the standard one. For example: > > class Mymongo(models.Model): > . > > class Meta: > auto_field_class = MyMongodbAutofieldClass > > IMHO, this could be an easy and fast way to deal with the AutoField > issue. Instead of specifying the AutoField class in Meta you can just use class Mymongo(models.Model): id = MyMongodbAutofieldClass() ... Apart from that, we'd need a plan for maintaining backward-compatibility because an AutoField that supports string values has a different validation behavior which might break existing code. Russell already suggested to check if the user only has SQL backends and then handle validation accordingly. During the transition phase a warning would be shown during AutoField validation errors, telling the user that the validation behavior will change in a future release and he has to modify his code. If someone uses a NoSQL backend the new validation behavior would be enabled automatically. Bye, Waldemar Kornewald -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- 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.
A word of thanks.
Hi all, Django is truly outstanding software. Thank you all for your great work. -- 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: A word of thanks.
On Mon, Aug 23, 2010 at 1:56 AM, Timothy Makobu wrote: > Hi all, > > Django is truly outstanding software. Thank you all for your great > work. On behalf of the core team, and the huge community of developers that have contributed to Django -- you're welcome! If you want to show your appreciation in other ways, the very best way is to pitch in. There's lots you can do to help out, regardless of your level of experience. Visit the contributions guide for more details [1]. [1] http://docs.djangoproject.com/en/dev/internals/contributing/ 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: Query Refactor Final Status Update
On Mon, Aug 23, 2010 at 5:21 AM, Waldemar Kornewald wrote: > Hey Flavio, > > On Sun, Aug 22, 2010 at 12:40 PM, FlaPer87 wrote: >> Hi Alex, >> >> I agree about leaving the backend outside django too (IMHO, all >> backends should live outside django). Is there any link that points to >> the apps you used for tests and to the mongodb backend? >> >> As you might know, We've been working on a django_mongodb_engine that >> uses django-nonrel and djangotoolbox. It currently works well (we use >> it in production) and it would be great to integrate part of our work >> with yours if it is possible. > > Yes, you should definitely do that. I already told Alex that the > MongoDB backend has to merge filters sometimes. For example, I think > Alex' MongoDB backend won't work with filter(x__gt=3, x__lt=5), please > correct me if I'm wrong. I implemented support for merging filters in > django_mongodb_engine, so you could reuse at least that. > > Apart from that I just remembered a little issue in the current ORM: > is_null queries on ForeignKey generate code which requires a JOIN. > This inefficiency should probably also be fixed before 1.3 stable gets > out. There is an issue for this, already: > http://code.djangoproject.com/ticket/10790 > >> As Waldemar said, the AutoField issue should be dealt before merging >> and I would suggest to leave the non standard AutoField definition to >> the backends and then adding an attr into the Meta class that >> specifies the class that should be used for AutoFields in case it >> isn't the standard one. For example: >> >> class Mymongo(models.Model): >> . >> >> class Meta: >> auto_field_class = MyMongodbAutofieldClass >> >> IMHO, this could be an easy and fast way to deal with the AutoField >> issue. > > Instead of specifying the AutoField class in Meta you can just use > > class Mymongo(models.Model): > id = MyMongodbAutofieldClass() > ... > > Apart from that, we'd need a plan for maintaining > backward-compatibility because an AutoField that supports string > values has a different validation behavior which might break existing > code. Russell already suggested to check if the user only has SQL > backends and then handle validation accordingly. During the transition > phase a warning would be shown during AutoField validation errors, > telling the user that the validation behavior will change in a future > release and he has to modify his code. If someone uses a NoSQL backend > the new validation behavior would be enabled automatically. The AutoField issue is the biggest impediment I see to merging code to trunk. Most of the other changes Alex has proposed are fairly innocuous (and, with hindsight, probably should have been done as part of the multi-db changes). Hopefully we'll get a chance to thrash out these issues at DjangoCon. Alex - congratulations on another completed Summer of Code, and thanks for your hard work over the summer! 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: [gsoc/app-loading] final status report
Hi Arthur,
thanks for your work!
Is any syntax of setting keywords for app instances in INSTALLED_APPS
or somewhere in settings supported now?
On Mon, Aug 23, 2010 at 2:06 AM, Arthur Koziel wrote:
> Hey there,
>
> the GSOC is over and I wanted to give you all a final status report.
>
> The AppCache was refactored and now creates app instances instead of just
> loading models. An app is either an instance of django.core.apps.App or a
> custom class. This depends on the entry in the INSTALLED_APPS setting. Here's
> an example:
>
> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.sites',
> 'myproject.poll.MyPollApp',
> )
>
> With this setting, three instances will be created. Two instances of the
> django.core.apps.App class and one MyPollApp instance. The MyPollApp class
> could look like this:
>
> from django.core.apps import App
> from django.utils.translation import ugettext as _
>
> class MyPollApp(App):
> def __init__(self, name):
> super(MyPollApp, self).__init__(name)
> self.verbose_name = _('Poll')
> self.db_prefix = 'foo'
>
> The first thing to note is the verbose_name attribute, which allows for a
> more descriptive name of the app. Currently the app name is the app_label, so
> "auth" would be used for "django.contrib.auth". However, something like
> "Authentication" would fit better from a UI perspective. The name can be
> passed to the ugettext function and translated in the projects .po file on
> the next run of makemessages. I modified the admin to use the verbose_name
> instead of the app_label.
>
> The db_prefix attribute allows the app to specify the prefix used when the
> tables are created in the database. If the above app would have a "Poll"
> model, it would be created as "foo_poll" instead of "poll_poll".
>
> There many more attributes than can be implemented like a fixture prefix or
> admin permission prefix. The models app label is currently used for far too
> many things.
>
>
>
> One thing I noticed was that a lot of code in Django itself or 3rd party apps
> iterates over the installed apps and imports them. This won't work anymore as
> an app can now also be a path to a class, so the import will raise an
> exception.
>
> The ideal solution would be to change the code to iterate over the app
> instances instead of the INSTALLED_APPS setting, but this might be a little
> bit too much to ask. So, there's now an "installed_apps" attribute on the
> AppCache that is a normalized version of the settings.INSTALLED_APPS variable
> (with classnames removed). This makes the migration easier as this code:
>
> for app in settings.INSTALLED_APPS:
> import_module(app)
>
> simply needs to be changed to this:
>
> for app in cache.installed_apps:
> import_module(app)
>
> Applications with the same app label still cannot be created. The problem is
> backwards compatibility, as the methods of the AppCache (get_model/get_app
> etc.) all take the app_label as an argument. If, for example, there would be
> two "auth" app instances (e.g. django.contrib.auth
> and myproject.auth) calling get_model('auth', ...) the function must still
> return the first one. I don't see migration path from app label to full path
> without breaking bc.
>
> Nevertheless, things have improved a little here. Previously, loading two
> apps with the same app label would assign the models of the second app to the
> first app, leaving the user with one auth app that mixed together the models
> from both apps. That won't happen anymore. Now there will be only one auth
> app, and the second will not be loaded. Hopefully this will clear up some
> confusion.
>
>
>
> Overall, I'm happy with the result. Working on this project was a great
> experience for me. I plan to continue my work on this branch after gsoc.
> Jannis Leidel was a fantastic mentor, always available and really helpful.
>
> I have the next 2 weeks filled up with exams but I'll be in Portland for
> DjangoCon in early September. I'm always open to feedback and planning on
> attending the sprints to do some further work. So until then...
>
> Regards,
> Arthur
>
> --
> 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.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
