Re: Models.py not loaded at server startup ?????
Hi, Is there a "clean" solution nowadays? I am making an app that should run some specific code after the whole project is loaded. I was thinking about a thread started in the models.py file of my app that will try X times to run the code, something like that: success = False attempts = 0 while not success and attempts < 10: attempts += 1 try: run() # raise Exception if it fails success = True except: pass if attempts == 10 and not success: # log or do something What do you think? Any ideas? Thanks. Michael Le lundi 13 décembre 2010 20:01:30 UTC+1, Pakal a écrit : > > I've never used these handlers yet, but from what I've browsed from > django's code, it seems low level handlers have nothing to import > models, so I guess the result would be the same. > I guess I'll manually import all my INSTALLED_APPS models from within > my settings.py or urls.py, for the moment. > > But I still don't understand : where are we supposed to connect > signals, then ? The signaling framework only makes sense if there is a > clear startup phase in the server code, else it's just a nasty (and > silent) trap for programmers, isn't it ? > > Regards, > Pakal > > > On 13 déc, 16:54, Harro wrote: > > Is this mod_python specific or does it also happen with mod_wsgi or > > gunicorn? > > > > On Dec 13, 3:47 pm, Carl Meyer wrote: > > > > > Hi, > > > > > On Dec 12, 4:40 pm, Pakal wrote: > > > > > > Why, then, isn't it specified that all models.py files should be > > > > loaded by each starting worker ? That would solve the whole problem > > > > and hidden errors around startup code like signals and startup > checks. > > > > > This is a real issue for me as well; not necessarily that models.py > > > isn't loaded at startup time, but the crucial difference in behavior > > > between runserver and a live deployment in terms of when apps' models > > > are imported, due to runserver performing model validation and thus > > > importing all models immediately. I have more than once seen code that > > > worked perfectly under runserver fail in subtle ways on real > > > deployment for this reason. (In fact, the most popular Django search > > > solution, haystack, is particularly susceptible to problems of this > > > type, as it does some dynamic importing immediately when its models.py > > > is imported). > > > > > So this is certainly on my radar screen as something I'd like to look > > > at in the 1.4 timeframe. I'm not sure yet what a good solution would > > > look like, and I'm not entirely convinced that importing all models.py > > > at startup time is the right answer. In any case, the Google Summer of > > > Code work by Arthur Koziel on app-classes will impact this area, and > > > is scheduled for merge in the 1.4 cycle, so I'm kind of waiting for > > > that to land before looking at this closely. > > > > > Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/XTvSa27MoaQJ. To post to this group, send email to django-developers@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: Moving forward with Serialization.
W dniu 31.08.2012 10:25, Tom Christie pisze:
> I personally think that Forms are already the place that should
handle (de)serialisation. They already serialise to HTML: why should
they not be able to serialise to other stream types?
Conceptually I agree. As it happens django-serializers is perfectly
capable of rendering into HTML forms, I just haven't yet gotten around
to writing a form renderer, since it was out-of-scope of the fixture
serialization functionality.
Pragmatically, I'm not convinced it'd work very well. The existing
Forms implementation is tightly coupled to form-data input and HTML
output, and I think trying to address that without breaking
backwards compatibility would be rather difficult. It's maybe easy
enough to do for flat representations, and pk relationships, but
extending it to deal with nested representations, being able to use a
Form as a field on another Form, and representing custom relationships
would all take some serious hacking. My personal opinion is that
whatever benefits you'd gain in DRYness, you'd lose in code
complexity. Having said that, if someone was able to hack together a
Forms-based fixture serialization/deserialization implementation that
passes the Django test suite, and didn't look too kludgy, I'd be
perfectly willing to revise my opinion.
I am not quite sure but I think Forms should be build based on some
serialization API not opposite. Forms are more precise way of models
serialization - they are models serialized to html (specific format)
with some validation (specific actions) when deserializing.
I like Tom's django-serialziers but there are some things that I want to
mention:
* Process of serialization is split to two parts - transformation to
python native datatype (serializer) and next to specific text format
(renderer). But when serializing also Field is saved with data so it's
not so clean. I also have an issues with this but I resolve it in
different way (not say better :)
* In master branch Serializer is closely tied to Renderer so if there is
different Renderer class than new Serializer is needed. In forms branch
it is done in __init__ serialize method and this must be rewrite for
backward compatibility if django-serializers goes to core. I want to
propose my solution [1]:
For each format there is Serializer class which is made from
NativeSerializer ( from models to python native datatype) and
FormatSerializer (Renderer)
class Serializer(object):
# class for native python serialization/deserialization
SerializerClass = NativeSerializer
# class for specific format serialization/deserialization
RendererClass = FormatSerializer
def serialize(self, queryset, **options):
def deserialize(self, stream_or_string, **options):
Deserializer = Serializer
This is fully backward compatible and user can do:
serializers.serialize('registered_format', objects,
serializer=MyNativeSerializer)
This will make new Serializer class with SerializerClass ==
MyNativeSerializer. In this solution NativeSerializer and
FormatSerializer are more independent. In my solution each
NativeSerializer can be render by each FormatSerializer but it's not so
simple. FormatSerializer provide NativeSerializer with some context so
you can tell that NativeSerializer knows what format will be serialized.
It's not exactly format but some metadata about it. I am not proud of
this :/
* IMO there is bug related to xml. All model fields must be transform to
text before xml serialization. In current django serialization framework
field's method value_to_string is responsible for this. In
django-serializers this method is not always called so it can lead to
error with custom model field
[1]
https://github.com/grapo/django/tree/soc2012-serialization/django/core/serializers
--
Piotr Grabowski
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
