Re: [django.contrib.postgres] Would this be accepted and how hard would it be to do?

2015-06-28 Thread Russell Keith-Magee
On Mon, Jun 29, 2015 at 7:32 AM, Josh Smeaton 
wrote:

> I'm not quite up to date on XML in databases (I've never had to use XML in
> a database), but don't the majority of core backends support XML in some
> way? If so, I'd probably like to see an attempt to build out XML support
> such that all/most core databases could benefit from the new feature,
> rather than being locked away in contrib.postgres.
>

Heh...

https://github.com/django/django/blob/stable/1.3.x/django/db/models/fields/__init__.py#L1135

So, to answer your questions:
>
> Is this a project that;
> a) would be accepted - Probably, if someone were to implement it and drive
> it until quality was acceptable
> b) would be fairly straight forward and - I'm not sure how straightforward
> it would be. The addition of Lookups and Transforms will help tremendously
> though.
> c) would be useful to the wider community? - Not for me personally, but
> I'm sure there'd be others that would find good use for XML support.
> Hopefully we can get some more feedback to accurately determine that though.
>

Broadly, I agree with Josh.

Given that we have contrib.postgres, we should be aiming at 100% coverage
of PostgreSQL features in core (not saying that is possible or likely, but
it's an aspirational goal).

In cases where it is plausible to implement a feature for all backends, we
should aim to do that.

However, I don't think we should be cross platform at all costs. It would
be possible to implement XMLField as a light layer over TextField (hey - we
used to do exactly this), but if that's the only way to implement it, I
don't think we should implement it at all. I'm not in favour of
implementing known-to-be-slow design patterns for core features. Unless
SQLite and MySQL offer a native XML data type, with reasonably rich query
syntax, then I don't think a cross-platform is desirable.

Yours,
Russ Magee %-)

-- 
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...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-fksB0S6bpvwj-tBTttiSaVmK5Vzx%2B9b7NrtGeFOWevw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [django.contrib.postgres] Would this be accepted and how hard would it be to do?

2015-06-28 Thread Josh Smeaton
I'm not quite up to date on XML in databases (I've never had to use XML in 
a database), but don't the majority of core backends support XML in some 
way? If so, I'd probably like to see an attempt to build out XML support 
such that all/most core databases could benefit from the new feature, 
rather than being locked away in contrib.postgres.

So, to answer your questions:

Is this a project that; 
a) would be accepted - Probably, if someone were to implement it and drive 
it until quality was acceptable
b) would be fairly straight forward and - I'm not sure how straightforward 
it would be. The addition of Lookups and Transforms will help tremendously 
though.
c) would be useful to the wider community? - Not for me personally, but I'm 
sure there'd be others that would find good use for XML support. Hopefully 
we can get some more feedback to accurately determine that though.

Cheers,

On Sunday, 28 June 2015 11:19:08 UTC+10, Some Developer wrote:
>
> Hi, 
>
> I'm a long term Django user but have never contributed to the main 
> Django code base mainly because I haven't really needed any extra 
> features. Until now. 
>
> I only use PostgreSQL as my database and the recent addition of 
> django.contrib.postgresql got me thinking about other features of 
> PostgreSQL that could be added to the Django code base that would be 
> very useful for me and probably others. 
>
> Those features are PostgreSQLs built in support for the XML data type. 
> These could be supported in Django with the addition of an XMLField. 
> Because PostgreSQL supports querying the XML data directly some 
> additions would have to be made to support these operations in the ORM 
> (I think at least). 
>
> I've just checked out the latest Django source code and notice that 
> there is a jsonb.py file in the django.contrib.postgres.fields package 
> which I assume will support JSON in PostgreSQL in version 1.9. I'd like 
> to do the same thing but with the XML data type. 
>
> Is this a project that a) would be accepted b) would be fairly straight 
> forward and c) would be useful to the wider community? JSON is great and 
> all but XML still has its uses in the world (I'm one of those people who 
> prefer JSON but XML just offers more for the project that I am working 
> on). 
>
> So thoughts? 
>

-- 
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...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d806737b-ab1d-44df-81e4-9e3c9d6a47a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: DEP django model internalization feedback

2015-06-28 Thread Ashley Camba Garrido
Damn, forgot the link.

https://github.com/ashwoods/deps/blob/master/draft/-model-internalization.rst


>
>

-- 
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...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3a863562-dd30-4be9-a017-dec95f541c14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


DEP django model internalization feedback

2015-06-28 Thread Ashley Camba Garrido
This is *rough* draft of something that I have been playing around with, 
with the help of anssi.

Tinkering around it seems that you can implement most of this with barely 
touching django,
or at least without breaking backward compatibility. Some of the major 
issues are almost philosophical :)
Specially the part about handling migrations caused by apps on tables that 
don't belong to them and stuff like that.

Before I follow this route I wouldn't mind getting some feedback.

Cheers,
ash

-- 
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...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/60e622e9-6d6d-4e4d-98bd-96e0f14ea9ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: URL dispatcher API

2015-06-28 Thread Marten Kenbeek
Hey,

I've been working on (re)building the new dispatcher API from the ground up 
at https://github.com/knbk/django/tree/dispatcher_api. 
As of this week it is passing the complete test suite, and I've replaced 
all occurrences of the old dispatcher with the new one. It's 
not 100% ready but it's getting closer. 

The API hasn't changed too much since my last post. After several 
iterations of the URL class, I went back to simply passing the remaining 
path, with the request as a second parameter. The URL class is now solely 
used in reverse() to reconstruct urls. After the View class has been 
merged in Resolver, I've now split Resolver into Resolver and 
ResolverEndpoint, with common functionality in BaseResolver. App names are 
now resolved to namespaces before calling resolver.search(), as the former 
method of resolving them on the fly posed some problems. 

The biggest issue still at hand is that `RegexPattern.construct()` can't 
always reliably determine which `normalized_pattern` to use if  there is 
more than one option. Using `reversed(self.normalized_patterns)` and trying 
all options from most specific to least specific might be enough 
in practice, but it can also be a cause for hard-to-debug problems. I 
haven't given it much attention yet, but I'm looking for an efficient way 
to 
solve this while maintaining a simple API for `construct()`. 

As always, feedback is welcome.

Marten

Op zondag 24 mei 2015 02:13:31 UTC+2 schreef Marten Kenbeek:
>
> Hi all,
>
> Thanks for the feedback. It's good to know I'm on the right track.
>
> I've pushed another commit that addresses most of the concerns raised 
> here. I've updated the example gist as well. 
>
> I'm also curious to learn more about this "set of decorators" that can 
>> be applied to a view by the url resolver - that feature doesn't seem to 
>> be documented in the linked gist or in the API example. 
>
>
> The idea is that sometimes, sets of views require a certain decorator - 
> i.e. the whole admin uses the staff_member_required decorator (and some 
> more stuff). This feature allows you to specify a list of decorators to 
> apply to a whole section of your site, and prevents a lot of code 
> duplication and the risk of missing a decorator somewhere (for example, if 
> you add additional views to the admin, you'll have to decorate them 
> yourself). 
>
> I am not at all sure that it is a good idea to mix layers in this 
>> suggested way, or what specific use case it improves. If the argument 
>> that a constraint matches is an integer, why is it (in practice) useful 
>> for the constraint to know that this integer is supposed to be the ID of 
>> some particular model class? Why is it good for that constraint, when 
>> reversing, to be able to take a model instance instead of an ID? To me 
>> this sounds like the sort of implicit type coercion that makes APIs 
>> harder to use and understand, not easier. 
>
>
> The constraints should be very explicit about what they accept. The 
> model_or_pk pattern is used all over Django, so I don't think it's *that* 
> much of a problem. I see two main advantages: you can easily change the 
> field in the url (e.g. from id to slug/uuid), and the regex pattern can be 
> inferred from the field. The latter certainly is more friendly to 
> beginners. But well, maybe it isn't my best idea ever. It doesn't have to 
> be in core, it's easy enough to create in a third-party app if people want 
> it.
>
> 1) The interplay between URL and Constraint is unclear. 
>
>
> I moved the constraints out of the URL class, so that the Constraint knows 
> about the URL. The URL is not strictly immutable, but I think that's 
> difficult to avoid. Now, `Resolver.match()` is a more-or-less atomic 
> operation that clones the old url, manipulates the clone through 
> `Constraint.match()` and returns it. After that, the URL shouldn't change. 
> When reversing, the URL is created from a set of constraints in one go. 
>
> The URL class is something I'm still working on. I particularly like the 
> option to build an url relative to the current request. That should 
> gracefully handle subdomains, and it can easily be extended to handle 
> schemes etc. It might not be needed in resolve(), though. I would like the 
> request object available, but that could be passed as a separate argument. 
> I don't think the pattern of cutting of the matching part should really be 
> extended to the host, so it would only need the path and request 
> parameters. 
>
> 2) The Resolver / View API can be simplified. 
>
>
> I was afraid that Resolver.resolve() would become too complicated, but 
> I've managed to keep it simple. I've brought back the ResolverMatch class 
> (which I would need for backwards compatibility anyway), and the decorator 
> functionality has been moved over there. The resolving functionality has 
> been moved to the Resolver class. This does feel quite a bit cleaner :)
>
> One important thing to keep in mind is reverse()