ModelForm enforces its version of save_m2m

2012-05-22 Thread James Pic 
Hello everybody,

Currently, Django ModelForm enforces it's local version of save_m2m:
https://github.com/django/django/blob/38408f8007eae21b9f1cbbcc7f86d4b2042ff86a/django/forms/models.py#L76

As a result, users who want to overload save_m2m can not support
commit=False: 
https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/contrib/generic_m2m.py#L50

Wouldn't it be great if users could overload save_m2m ?

If you agree, I volunteer to do the ticket and pull request. Else I'll
leave my hack in my app :(

Regards

-- 
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: Django git guidelines

2012-05-22 Thread Anssi Kääriäinen 


On May 18, 11:34 pm, Anssi Kääriäinen  wrote:
> > You are making a lot of assumptions about the branches someone might send
> > via pull request. It is entirely valid, and often _preferable_ that someone 
> > is
> > depending on these. Maybe they were running their site on this branch,
> > developing
> > the feature to support something they needed, or simply as a way to test it
> > in the wild. Maybe someone else based their own work on an existing topic
> > branch.
>
> > Also, we can't assume that merging back to upstream is the only reason 
> > someone
> > may have created this branch.
>
> I am talking about topic branches here. If you have a branch of "admin-
> next" for example then the workflow might need to be different.
>
> It seems the correct way to describe a Github topic branches is that
> they are just another way of publishing a _patch series_. In Linux
> this is done by sending the patches to LKML. We used to do this by
> Trac patches (still accepted) and now by pull requests in Github. The
> confusion comes from the note that "public branches should never be
> rebased". The topic branches should not be viewed as public branches,
> just as a way to publish patch series.
>
> I am not sure what to do with a pull request of a branch a site is
> depending upon. If the pull is not accepted into Django, how is the
> depended-upon branch supposed to continue and be acceptable for
> further pull requests into Django? If you merge and resolve conflicts
> (by a competing approach maybe), then you will have such a messy
> history it will not be pulled into Django. If you rebase, everybody
> depending on the branch will need to do the same. If you revert the
> rejected patch, then merge, you are again having a history which
> should not be merged into Django. Am I missing something important
> here?

I have done some more research. This post is somewhat long, so if you
want just the conclusions, it is enough to read the last three
paragraphs.

First, some useful links:
http://kerneltrap.org/Linux/Git_Management
http://sethrobertson.github.com/GitBestPractices/#workflow

>From the above, and elsewhere in the net, it is pretty easy to see
that getting the "sausage making" (see GitBestPractices link above)
steps into the core repository history is not wanted. Hiding sausage
making is just a way to say we want good logical commits, but we do
not want back-and-forth development commits into the history. Getting
the development commits into the history makes the history messier,
and it makes bisecting harder. Seeing a "final whitespace cleanup" as
the commit in git blame isn't good...

In Linux the workflow is as follows: topic branches are dealt in patch
format alone. This means that there are no public topic branches, and
this again means the patch author is free to rewrite the history at
will - and that the (subsystem) committer is free to do additional
edits to the patches when committing (I don't know if they do this -
but they could). The patches sent to the mailing lists will at least
sometimes need to go through a couple of cycles of review - tune, so
additional changes to the topic branches are usually required.

When the patch is good to go, the subsystem maintainer commits it.
After the commit, the patch is essentially part of the history of
Linux kernel already. Linus may reject it, or ask for some more
polishing, but he usually does not do this. The subsystem maintainer
is really the maintainer of that part of the kernel, and is officially
so. If for some reason revert is needed, the subsystem maintainer
simply reverts the patch, and Linux master will get the commit +
revert commit of the rejected patch.

The Git team uses a different workflow: they have public branches they
reset once in a while. The 'pu' (proposed updates) branch mentioned in
these links: 
http://www.kernel.org/pub/software/scm/git/docs/v1.7.2.2/gitworkflows.html,
http://stackoverflow.com/a/5713627. So, even the Git developers do
rebase / reset public branches. We do not have a "pu" branch, but one
might be a good idea in the future.

In the http://kerneltrap.org/Linux/Git_Management link Linus argues
that public branches should never be rebased - and his take on this is
very strict, this would apply to any branch that is potentially
public, and thus to github topic branches too. This would cause a
messy history to appear in the commit history of the topic branches,
and as mentioned above this is not a good idea.

For the idea of making pull requests from a branch which a site is
based on the answer is: sorry, it does not work that way. This turns
the dependency around - the branch the site is dependent on should not
dominate Django's development. Only official subsystem branches have
the property that their history is part of Django's history. The
possible tunings/reverts in the site-based branch have no business of
getting into Django's history. What the pull requester should do is
cherry pick the commits he/she wants to pu

Re: Re-design "proposal" for djangoproject.com

2012-05-22 Thread Adam "Cezar" Jenkins 
On Mon, May 21, 2012 at 6:15 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> So - if you think there's a need for a showcase site -- go ahead and build
> it!
>
>
http://www.djangosites.org/ has been around quite a while IIRC? I remember
it being around four or five years ago. Is it still active?




> 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-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: auth.user refactor: the profile aproach

2012-05-22 Thread Bernardo Pires 
Sorry for reviving this thread. Are the auth mixins fork from ogier going 
to be commited to the django master branch anytime soon? I'd like to 
"officially" use it. Is there any documentation available? Thanks in 
advance.

Am Dienstag, 3. April 2012 02:35:41 UTC+2 schrieb Jacob Kaplan-Moss:
>
>  Hi folks -- 
>
> I've written up a proposal for how *I* would like to address refactoring 
> auth.user: https://gist.github.com/2245327.
>
> In essence, this does two things:
>
> * Vastly "prunes" the required fields on auth.user. The only things left 
> are an "identifier" (which could be username, email, url, uuid, whatever), 
> and a password.
> * Introduces a new "profile" system that provides a way to contribute 
> extra related fields. Multiple profiles are supported, along with some 
> syntactic sugar for dealing with multiple profiles in a reasonably reusable 
> way.
>
> And that's about it. I'm deliberately trying to find a middle ground 
> between "do the minimum to allow people to move on" and "throw out and 
> rewrite django.contrib.auth entirely". I'm not expecting everyone to be 
> thrilled by this idea, but I'm hoping that this is "Good Enough" for almost 
> everyone.
>
> For more please see the document. Please do try to read the whole thing: 
> I've had a few rounds of feedback incorporated already, and there's even an 
> FAQ at the end.
>
> I'm not using BDFL fiat here, at least not yet. This is a proposal, and I 
> very much want to hear feedback, objections, and alternatives. I'm 
> particularly interested in hearing from people who've got complicated auth 
> needs and think this absolutely won't work for them. 
>
> I *have* reviewed all the other proposals and I'm between -0 and -1 on all 
> of them. This means that if you don't like my proposal, you'll probably 
> have to come up with a complete *new* idea to have any chance of getting my 
> vote.
>
> Thanks!
>
> Jacob
>  

-- 
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/-/wprtljceILUJ.
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: Multi-tenant Django

2012-05-22 Thread Bernardo Pires 
Hello guys,

Have you guys taken a look at  
https://github.com/phugoid/django-simple-multitenant?
I'm not a big fan of one database per tenant as I think this can get quite 
out of hand very easily (migrating models on every single database). The 
app linked above simply adds a foreign key to all models needed, so that 
you can infer which Tenant you are talking about. I've been thinking of 
using it on my next project. Any suggestions? Thanks in advance.

Bernardo Pires

Am Mittwoch, 9. Mai 2012 05:02:45 UTC+2 schrieb Alec Taylor:
>
> Dear Django-developers, 
>
> I've been using Django for a few months now, and recently—for 
> different projects—started using the web-framework: web2py[1], and the 
> Django project: mezzanine[2]. 
>
> Both advertise as being multi-tenant solutions[3][4]. 
>
> Would it be possible to extend Django to meet this use-case? — Or have 
> I overlooked something and is this possible already? 
>
> Thanks for all information, 
>
> Alec Taylor 
>
> [1] http://www.web2py.com/ 
> [2] http://mezzanine.jupo.org/ 
> [3] https://groups.google.com/forum/#!topic/mezzanine-users/4XPe5MaD4Fw 
> [4] PyCon 2012 talk: http://youtu.be/M5IPlMe83yI?t=5m32s 
> http://dl.dropbox.com/u/18065445/Slides/PySFTalkSlides.pdf (slide42, 
> see yt for more info) 
>

-- 
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/-/xu90OdufzBkJ.
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: Re-design "proposal" for djangoproject.com

2012-05-22 Thread Russell Keith-Magee 
On Tue, May 22, 2012 at 8:55 PM, Adam "Cezar" Jenkins
 wrote:
> On Mon, May 21, 2012 at 6:15 PM, Russell Keith-Magee
>  wrote:
>>
>>
>> So - if you think there's a need for a showcase site -- go ahead and build
>> it!
>>
>
> http://www.djangosites.org/ has been around quite a while IIRC? I remember
> it being around four or five years ago. Is it still active?

Well, the site has been around for a while, and  is still up. It's
even linked from the current homepage (indirectly -- you have to go
via the wiki). I can't comment on how actively it's being maintained.

However, while it's a reasonable index, but I don't think it's a very
good showcase -- at least, not in it's current form.

The first page you see on the site lists a bunch of sites I've never
heard of. The 5 "Highest rated" sites are apparently: paste
DjangoSites, SuggestionBox, Chesspark, and Music Discipline.

These may all be fine sites, but if I were trying to showcase
commercial usage of Django, I'd start with sites that people have
actually heard of -- sites like Mozilla, Disqus, Pinterest and
Instagram. As far as I can make out, none of these 4 are even in the
djangosites index.

So - Djangosites might be the starting point for a showcase site; but
it needs a whole lot of attention before it's "front page" material,
IMHO. In particular, it needs some editorial control -- someone who is
actively selecting content that showcases the best of Django, rather
than relying on the community to hopefully contribute and promote good
sites.

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-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: Multi-tenant Django

2012-05-22 Thread charettes 
The "migrating models on every database issue" can be solved easily by 
creating a command that calls the specified one using `call_command` and 
passing the correct `db` kwarg to the underlying one.

Say you have installed South and want to call the `migrate` with two 
underlying dbs.

./manage.py multidbwrappercmd migrate --all

Would internally do:

call_command('migrate', all=true, db='db1')
call_command('migrate', all=true, db='db2')

Le mardi 22 mai 2012 09:50:49 UTC-4, Bernardo Pires a écrit :
>
> Hello guys,
>
> Have you guys taken a look at  
> https://github.com/phugoid/django-simple-multitenant?
> I'm not a big fan of one database per tenant as I think this can get quite 
> out of hand very easily (migrating models on every single database). The 
> app linked above simply adds a foreign key to all models needed, so that 
> you can infer which Tenant you are talking about. I've been thinking of 
> using it on my next project. Any suggestions? Thanks in advance.
>
> Bernardo Pires
>
> Am Mittwoch, 9. Mai 2012 05:02:45 UTC+2 schrieb Alec Taylor:
>>
>> Dear Django-developers, 
>>
>> I've been using Django for a few months now, and recently—for 
>> different projects—started using the web-framework: web2py[1], and the 
>> Django project: mezzanine[2]. 
>>
>> Both advertise as being multi-tenant solutions[3][4]. 
>>
>> Would it be possible to extend Django to meet this use-case? — Or have 
>> I overlooked something and is this possible already? 
>>
>> Thanks for all information, 
>>
>> Alec Taylor 
>>
>> [1] http://www.web2py.com/ 
>> [2] http://mezzanine.jupo.org/ 
>> [3] https://groups.google.com/forum/#!topic/mezzanine-users/4XPe5MaD4Fw 
>> [4] PyCon 2012 talk: http://youtu.be/M5IPlMe83yI?t=5m32s 
>> http://dl.dropbox.com/u/18065445/Slides/PySFTalkSlides.pdf (slide42, 
>> see yt for more info) 
>>
>

-- 
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/-/ZIuA2r4QOCsJ.
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.

Announcement: twice-monthly Django sprints in San Francisco

2012-05-22 Thread Jeremy Dunck 
My company, Votizen, now has an office in San Francisco, just a block
from the 4th St Caltrain station.  We have room to host sprints -
easily 25 people, though we can grow if there is demand.  We have a
professional kitchen, great coffee gear, and maybe a kegerator soon.
There are many great places to eat within an easy walk.

We will begin hosting day-long, twice-monthly sprints for Django on
the 1st and 3rd Saturdays of each month.  We hope that by making it a
comfortable length and a regular occurrence, we can grow a good core
of contribution.

Note: this first sprint will be on Sunday, June 3rd due to a prior
commitment - sorry about that. :-)

Since we need to manage space and setup demands in order to make this
a regular event, we'll use eventbrite for free tickets.

If your company would like to sponsor food & beverage on a per-event
basis, that would be appreciated.  Please contact me off-list for
logistics.

So, if you are in the bay area and would like to contribute,
collaborate, mentor or be mentored, you are invited to attend - please
sign up:
  http://sfdjangosprint.eventbrite.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-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: Django git guidelines

2012-05-22 Thread Richard Laager 
On Tue, 2012-05-22 at 04:18 -0700, Anssi Kääriäinen wrote:
> if the patch author doesn't do the final squashing, then
> she/he will not end up as the "Author" in the commit logs. 

This isn't an issue. Just do:
git commit --author "John Doe "

And if the "squash merge" workflow (which isn't something I've used)
doesn't allow you to set the author, then just follow it by:
git commit --amend --author "John Doe "

-- 
Richard


signature.asc
Description: This is a digitally signed message part

Re: Django git guidelines

2012-05-22 Thread Alex Ogier 
On Tue, May 22, 2012 at 4:34 PM, Richard Laager  wrote:
> On Tue, 2012-05-22 at 04:18 -0700, Anssi Kääriäinen wrote:
>> if the patch author doesn't do the final squashing, then
>> she/he will not end up as the "Author" in the commit logs.
>
> This isn't an issue. Just do:
>    git commit --author "John Doe "
>
> And if the "squash merge" workflow (which isn't something I've used)
> doesn't allow you to set the author, then just follow it by:
>    git commit --amend --author "John Doe "
>

Git actually has native support for this workflow. Each commit has an
"author" and a "committer" which are typically the same, but in the
case of a squash merge or patch are different.

For example, 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=72c04af9a2d57b7945cf3de8e71461bd80695d50

Best,
Alex Ogier

-- 
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: New Release of IBM_DB_DJANGO (1.0.4)

2012-05-22 Thread Daniel Sokolowski 

Is it a licensing issue that this is not included in core?

-Original Message- 
From: Rahul

Sent: Wednesday, May 16, 2012 6:18 AM
To: Django developers
Subject: New Release of IBM_DB_DJANGO (1.0.4)

IBM_DB_DJANGO-1.0.4
---
IBM_DB_DJANGO adaptor enables access to IBM databases from Django
applications http://www.djangoproject.com/. The adaptor is developed
and maintained by IBM.

What's New?

- Added support for Django-1.4

- Backward compatibilty - Same codebase works with older supported
version of Django

- Added support to enable Django's USE_TZ feature

- Added support for Django's bulk_create

- Added support for 'SELECT FOR UPDATE'

- Added module version string __version__


SVN access to the source
---
http://code.google.com/p/ibm-db/source/browse/trunk/IBM_DB/ibm_db_django/

Installation

$ easy_install ibm_db_django

Feedback/Suggestions/Issues

You can provide us feedback/suggestions, or report a bug/defect, or
ask for help by using any of the following channels:
1. Mailing us at open...@us.ibm.com
2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list.
3. By opening new discussion at http://groups.google.co.in/group/ibm_db.
For prerequisites, installation steps and help details, visit -
http://code.google.com/p/ibm-db/wiki/ibm_db_django_README
Try this out and let us know you valuable feedback. Have fun.

Cheers,
Rahul Priyadarshi

Download Express-C for free, go to:
---
-
http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01&S_TACT=ACDB2011

--
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: Django git guidelines

2012-05-22 Thread Anssi Kääriäinen 
On May 22, 11:54 pm, Alex Ogier  wrote:
> On Tue, May 22, 2012 at 4:34 PM, Richard Laager  wrote:
> > On Tue, 2012-05-22 at 04:18 -0700, Anssi Kääriäinen wrote:
> >> if the patch author doesn't do the final squashing, then
> >> she/he will not end up as the "Author" in the commit logs.
>
> > This isn't an issue. Just do:
> >    git commit --author "John Doe "
>
> > And if the "squash merge" workflow (which isn't something I've used)
> > doesn't allow you to set the author, then just follow it by:
> >    git commit --amend --author "John Doe "
>
> Git actually has native support for this workflow. Each commit has an
> "author" and a "committer" which are typically the same, but in the
> case of a squash merge or patch are different.

The catch was meant to be that you won't get to be official author if
you don't do the final polish yourself. Maybe that isn't the brightest
of idea, we would probably still want that author information in this
case, too.

The more I work with the pull requests, the clearer it is that we need
not be overly pedantic with requiring the author to do all the
polishing. Requiring the author to remove one space, then waiting for
that space to be removed and finally merging the work is a lot more
laborious than just doing this simple change on commit.

So, I will try to reword the doc changes to suggest a lightweight path
for those who just want their change into Django (patch in Trac ticket
or a pull request, no need for good commit messages or rebasing), and
then have documentation for how to create perfect commit ready pull
requests, and suggest trying to use that path if the contributor wants
to contribute to Django more than just a single patch.

This is very much work in progress and I expect more changes to the
workflow still.

Thank you all very much for the feedback so far,
 - Anssi

-- 
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: New Release of IBM_DB_DJANGO (1.0.4)

2012-05-22 Thread Anssi Kääriäinen 
On May 23, 12:35 am, "Daniel Sokolowski"
 wrote:
> Is it a licensing issue that this is not included in core?

I don't know about licensing... I believe the issue is that we don't
have enough manpower to keep more backends updated in core. Even now
the Oracle backend is somewhat problematic - there aren't that many
contributors (or committers for that matter) who have Oracle
installed, and thus it is somewhat common that commits break that
backend. Then we fix those errors afterwards when/if we spot the
errors. Adding another not commonly available backend to the matrix
would cause more similar problems.

Having the backend in core is somewhat problematic for the above
reasons. But not having the backends in core is problematic for the
users... Still, at least for now it is better for the backends to live
outside core.

BTW I have just committed some patches with the aim of making the full
Django test suite pass when using django-mssql (another 3rd party
backend). If there is need and interest for similar work for DB2 I am
willing to commit patches...

 - Anssi

-- 
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: New Release of IBM_DB_DJANGO (1.0.4)

2012-05-22 Thread Ian Kelly 
On Tue, May 22, 2012 at 4:07 PM, Anssi Kääriäinen
 wrote:
> I don't know about licensing... I believe the issue is that we don't
> have enough manpower to keep more backends updated in core. Even now
> the Oracle backend is somewhat problematic - there aren't that many
> contributors (or committers for that matter) who have Oracle
> installed, and thus it is somewhat common that commits break that
> backend. Then we fix those errors afterwards when/if we spot the
> errors. Adding another not commonly available backend to the matrix
> would cause more similar problems.

I try to make a point of running the Oracle backend through the test
suite in the lead-up to each minor release and fixing whatever I find.
 Unfortunately, I rarely find the time to do much more than that these
days.  I wonder whether Oracle would even make it into core if the
decision were revisited.

-- 
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: Multi-tenant Django

2012-05-22 Thread Anthony Briggs 
I did a similar thing for some of my projects - the problem is that you
can't reuse any non-multitenant apps without hacking the multitenant stuff
in first, ie. it's a bit of a hack, plus it makes things harder to maintain
going forwards.

One database per tenant should (in theory) make life much simpler.

Anthony


On 22 May 2012 23:50, Bernardo Pires  wrote:

> Hello guys,
>
> Have you guys taken a look at
> https://github.com/phugoid/django-simple-multitenant?
> I'm not a big fan of one database per tenant as I think this can get quite
> out of hand very easily (migrating models on every single database). The
> app linked above simply adds a foreign key to all models needed, so that
> you can infer which Tenant you are talking about. I've been thinking of
> using it on my next project. Any suggestions? Thanks in advance.
>
> Bernardo Pires
>
> Am Mittwoch, 9. Mai 2012 05:02:45 UTC+2 schrieb Alec Taylor:
>
>> Dear Django-developers,
>>
>> I've been using Django for a few months now, and recently—for
>> different projects—started using the web-framework: web2py[1], and the
>> Django project: mezzanine[2].
>>
>> Both advertise as being multi-tenant solutions[3][4].
>>
>> Would it be possible to extend Django to meet this use-case? — Or have
>> I overlooked something and is this possible already?
>>
>> Thanks for all information,
>>
>> Alec Taylor
>>
>> [1] http://www.web2py.com/
>> [2] http://mezzanine.jupo.org/
>> [3] https://groups.google.com/**forum/#!topic/mezzanine-users/**
>> 4XPe5MaD4Fw
>> [4] PyCon 2012 talk: 
>> http://youtu.be/M5IPlMe83yI?t=**5m32s
>> http://dl.dropbox.com/u/**18065445/Slides/**PySFTalkSlides.pdf(slide42,
>> see yt for more info)
>>
>  --
> 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/-/xu90OdufzBkJ.
>
> 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: New Release of IBM_DB_DJANGO (1.0.4)

2012-05-22 Thread Mario Briggs 
>>

On May 23, 3:07 am, Anssi Kääriäinen  wrote:
> On May 23, 12:35 am, "Daniel Sokolowski"
 If there is need and interest for similar work for DB2 I am
> willing to commit patches...
>
Anssi, thank you very much for the offer. We (IBM_DB_DJANGO team) will
certainly reach out to you if we are in need of this

regards
Mario

-- 
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.