Re: JsonField
On Mon, Nov 7, 2011 at 9:58 PM, Ric wrote: > django should be able to handle this kind of situation, and please > don't be arrogant. Hi, I'm sorry you felt that I was being arrogant - I don't know the situations of your project, it may well be exactly what is needed in that situation. I was only trying to point out why in general it is not a good idea to do this, and why that would mean it shouldn't be in core. Cheers Tom -- 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.
Re: JsonField
On Mon, Nov 7, 2011 at 11:48 PM, Torsten Bronger wrote: > > While I appreciate that Django core is supposed to enforce good > design practices, one must be careful with that if some practice may > have valid use cases. You cannot prevent the user from shooting in > the foot anyway. > > While we make extensive use of the relational model in our project, > I remembered to have a couple of JSON fields (though we don't have a > field class them them so far), so I skimmed through our code to see > why we did this. > And so do I - the main point here is that we have both successfully loaded the gun and aimed it at our foot without this field existing in core. I think it's important to have that distinction between things you can do and things you should do, in order to make you think "should I really be doing this". Cheers Tom -- 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.
Re: Python 3 and you
Yes I know but Vista isn't the best platform and my laptop isn't that hot! Plus I have very good Unix/Linux experience, which may help. Richard On Nov 7, 2:01 pm, "Jonas H." wrote: > On 11/07/2011 12:00 PM, richard.prosser wrote: > > > I may be willing to support this. I have 18 month's of Python > > experience (mostly 2.4) and I have been out of work for a long time > > due to illness, so a project like this may look good on my CV! > > > I have never been involved in an OS project before, though I am aware > > of the guidelines. > > > At present the only machine I have available is a Windows Vista > > laptop :-( Are there development/test servers available? > > You don't need a Linux/Unix since Python/Django works on Windows. -- 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.
Re: Python 3 and you
If you want to test Linux deployment, install Ubuntu under VirtualBox: https://www.virtualbox.org/ Brian Schott bfsch...@gmail.com On Nov 8, 2011, at 11:37 AM, richard.prosser wrote: > Yes I know but Vista isn't the best platform and my laptop isn't that > hot! > > Plus I have very good Unix/Linux experience, which may help. > > Richard > > > On Nov 7, 2:01 pm, "Jonas H." wrote: >> On 11/07/2011 12:00 PM, richard.prosser wrote: >> >>> I may be willing to support this. I have 18 month's of Python >>> experience (mostly 2.4) and I have been out of work for a long time >>> due to illness, so a project like this may look good on my CV! >> >>> I have never been involved in an OS project before, though I am aware >>> of the guidelines. >> >>> At present the only machine I have available is a Windows Vista >>> laptop :-( Are there development/test servers available? >> >> You don't need a Linux/Unix since Python/Django works on Windows. > > -- > 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. > -- 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.
Re: JsonField
Hi, guys, I agree that we should use the right tool for the job; But even a relational database can be used for semi-structured data when it's not going to be directly queried. Matter of fact, there's even a design pattern recognized for that: http://martinfowler.com/eaaCatalog/serializedLOB.html Example of use: think of a semi-structured data store (in a relational database) that is going to be read through a search engine (think about ElasticSearch of Solr, here). But yes, if you're going to need to query for this data by parts of the JSON field, then you're shooting your own foot. So, in the end, we have to think a lot about what's the problem we're trying to solve - it's not as simple as "don't use RDBMS for non-relational data" -, IMHO. Well, at least here's my 2 cents. Cheers, Diogo On 8 nov, 08:34, Tom Evans wrote: > On Mon, Nov 7, 2011 at 11:48 PM, Torsten Bronger > > wrote: > > > While I appreciate that Django core is supposed to enforce good > > design practices, one must be careful with that if some practice may > > have valid use cases. You cannot prevent the user from shooting in > > the foot anyway. > > > While we make extensive use of the relational model in our project, > > I remembered to have a couple of JSON fields (though we don't have a > > field class them them so far), so I skimmed through our code to see > > why we did this. > > And so do I - the main point here is that we have both successfully > loaded the gun and aimed it at our foot without this field existing in > core. I think it's important to have that distinction between things > you can do and things you should do, in order to make you think > "should I really be doing this". > > Cheers > > Tom -- 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.
Re: Request for review / Multiple time zone support for datetime representation
Hi Aymeric,
Finally got around to this! My review follows. I didn't follow the
original discussions very closely, so forgive any questions that have
been answered already. On the other hand, the code and comments probably
ought to answer the kind of questions I have, without needing to search
mailing list archives, so it might be useful that I haven't been
following that closely.
The code looks in very good shape. I've got quite a lot of things listed
below, but the vast majority of my comments are small or very small nits
that can be easily corrected, with the possible exception of my
questions regarding django.utils.timezone.LocalTimezone
== django/contrib/admin/util.py ==
>elif isinstance(field, models.DateField):
>return formats.localize(timezone.aslocaltime(value))
>elif isinstance(field, models.DateField) or isinstance(field,
models.TimeField):
>return formats.localize(value)
Isn't the first clause in the second elif rendered useless by the
previous elif?
== django/db/backends/mysql/base.py ==
> # Finally, MySQLdb always returns naive datetime objects.
Is it possible that a future version of MySQLdb could change this? If
so, would it be better to not make this assumption, and future proof the
code? We could perhaps just add an assertion for the assumption we make,
so that we don't end up silently corrupting data with a future version
of MySQLdb that acts differently, because at the moment the function
datetime_or_None_with_timezone_support just wipes out any existing
tzinfo field.
There is a similar issue in the Oracle backend I think.
> raise ValueError("MySQL backend does not support timezone-aware
datetimes.")
This seems to be misleading - shouldn't the message add the caveat "if
USE_TZ == False" or something?
== django/db/backends/oracle/base.py ==
> raise ValueError("Oracle backend does not support timezone-aware
datetimes.")
As above, should add "if USE_TZ == False"
> def output_type_handler(cursor, name, defaultType,
> size, precision, scale):
tiny nit - is there a reason for camelCase just for the defaultType
variable?
== django/db/backends/sqlite3/base.py ==
> supports_timezones = False
What exactly is meant by this? The timezone support in the sqlite
backend appears to be very similar to that in MySQL.
If SQLite genuinely does not support time zones in some important way,
this should probably be noted in the release notes, and definitely in
docs/ref/databases.txt
== django/utils/timezone.py ==
> import time as _time
There doesn't seem to be any clash to avoid, so I don't see the need for
importing like this.
However, my biggest question is about the LocalTimezone class. We now
have two implementations of this, one in django.utils.tzinfo, which
seems to have more extensive tests, and a new one in
django.utils.timezone. The old one is still in use, both by old code
e.g. in django/contrib/syndication/views.py and new code e.g.
django/utils/dateformat.py under DateFormat.__init__
The new one is used in other places.
There is no explanation of the need for these two, or when they should
be used, which to me seems like a minimum requirement.
Perhaps we just need to combine the two LocalTimezone implementations in
tzinfo.py? If we can't do that for some backward compatibility reasons,
can we have some explanation, and preferably a deprecation path for the
older code? Finally, do we need to address code that uses the old
LocalTimezone in some way - should it be unconditionally using our own
LocalTimezone instead of something from pytz when available?
> # This function exists for consistency with get_default_timezone_name
> def get_default_timezone_name():
I'm guessing the comment should refer to get_current_timezone_name instead?
> def is_aware()
It is probably worth adding a comment indicating that the logic is taken
straight from Python docs, with a link -
http://docs.python.org/library/datetime.html#available-types
== docs/ ==
Some instances of 'time-zone' can be found, instead of 'time zone'
== docs/howto/custom-template-tags.txt ==
> Filters and time zones
I think this section needs a 'versionadded' directive.
> to to your filter
^ typo
== docs/ref/models/querysets.txt ==
> When :doc:`time zone support ` is enabled, the
> database stores datetimes in UTC, which means the aggregation is
> performed in UTC. This is a known limitation of the current
> implementation.
This implies that when time zone support is not enabled, datetimes are
not stored in UTC - which is false at least for Postgres. Perhaps this
could be reworded in some way?
Similarly with the next warning about 'year', 'month' etc. lookups.
> - It includes the time zone for aware datetime objects. It raises
> an exception for aware time objects.
First instance of 'aware' should be 'naive'. Second sentence should end
'aware datetime or time objects' for completeness.
== docs/ref/utils.txt ==
Needs a versi
Re: Django application instances
Hi all,
Thanks for the responses
On 6 November 2011 23:45, Russell Keith-Magee wrote:
> Untrue -- #3591 has been the ticket tracking this idea for some time.
> The ticket even has a patch/branch that is just waiting for review.
> I've been wanting to do a review for some time, but life has conspired
> against me...
I've had a read through the ticket and I think I see the approach
being taken - would a view/model get the current app configuration by
then calling django.apps.find_app('my_app_label'), is that correct? If
so, I think that's problematic for multiple instances on the same
server, as my_app_label is hardcoded into the app.
The approach we took is to have the app_label defined in the
settings.py file in the instantiation of the app, so you can
instantiate the same app twice, but with two different labels (and
configs). The application framework then took the urlconf module for
that app, instantiated every view (which for us are class-based) and
then attached a "conf" object to it which the views could use to
access their configuration. The root urlconf then needed to use the
urlconf objects attached to the application instance, rather than the
"raw" urlconf in the includes in order to get this to work. Multiple
app instances is then fairly straight forward from this point.
A more generic way that could be used is to perhaps use the extra
kwargs feature of the urlconf to pass in a new kwarg to the view
(perhaps called _conf) which has the instance of that application's
configuration which can be accessed by views as they please.
> The focus of this branch has been to turn an "Application" into a
> configurable object; this would allow app designers to define
> configuration points that are set at time of deployment.
>
> The one major aspect that you've described but isn't covered by the
> current patch on #3591, is the idea of having multiple instance of the
> same app in a single project. This introduces the complication that
> database table names need to include a deploy-time component (i.e.,
> some sort of instance identifier), which, IIRC, was punted from the
> goal list for the SoC project that yielded this patch. However, to
> the best of my knowledge, the approach described in the current patch
> *could* be used to handle the multiple instance scenario; it just
> hasn't been implemented.
We implemented this in a possibly non-elegant way, with our models
being naive, and our controllers doing queries based on the local_name
attribute (equivalent to the app_label).
Chris
--
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.
