Re: Composite Primary Keys
El 28/08/2008, a las 0:27, David Cramer escribió:
> Really I'm stuck at an architectural point.
>
> I have database validation and synchronization done, and the admin
> is working.
>
> What is left is more or less handling relatedfield lookups. The
> issue is, that field's are designed to reference more than one
> field, so it's a tough design deicision to make on how that should
> be approached.
I think the best (and the only one right) solution involves adding
multicolumn fields to Django and doing lookups with some syntax like
Model.objects.get(pk=('foo', 1)). There are other hackish approaches,
like using hash(tuple(pk[0], pk[1], ..., pk[n])) as foreign key, that
could work. However, I won't rely on them, since I'm not sure if
hash() implementation is guaranteed to be kept as is.
On other related point, what's the status of multicolumn fields?
Regards,
Alberto
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Porting Django to Python 3.0 as a GSoC project
El 28/03/2008, a las 11:50, Michael Radziej escribió: > > Hi, > >> [ugly stories about other source transformer tools and >> how they failed deleted] Not to understimate the student nor the Python community, but think about it in terms of developer time. TrollTech worked on Qt4 for some years with multiple developers and couldn't provide a decent automatic code translator for translating the codebase at build time. On the other hand, it did something right: provide a starting ground for projects moving from the old to the new version of the toolkit. > > I don't understand all the negative thinking. > > Django would probably be a great show case to see whether the planned > transition to python 3.0 works as it is designed. If things do not > work out, > this might still influence the python 3 development. > I see it as a win-win situation: python developers get a lot of > feedback > from a real-world project, and Django might get a lot for shifting > to python > 3. The student would learn a lot about both Django and python 3. > I see a clear win for Python and the 2to3 tool, but not for Django. As others have said, Python will change a lot before reaching 3.0, both in terms of Python code as C API and even Guido expects a five year transition. So you'll end up with a half baked solution which is likely to stale. Again, not to understimate the students, but I've seen lots of semi-finished GSoC projects in the latest years (take a look at the GPE and Maemo lists, almost none of the students followed contributing after SoC ended). So, it's really important to define a project which can be completely done over the summer, and I think this is not the case. > And in the end, Django is in no way obliged to take the resulting > code. > What's the point of accepting a project when you aren't thinking in taking the resulting code? > No worries 8-) ;-) Regards, Alberto --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Porting Django to Python 3.0 as a GSoC project
El 28/03/2008, a las 5:42, Sage La Torra escribió: > > I'll throw in my 2 cents too: > > I think machine based translation is iffy at best. I'm not the most > up-to-date on py3k, but I have experience with other such projects (I > wrote a Perl 5 to Perl 6 translator for Summer of Code 2006). This is > just my opinion, but I think it would be best for Django (and most > other python-based projects that are targeted at a large user bases) > to wait until python 3 hits a version where it has stabilized and then > do a port based on hand checking and modification of machine > translated code. > > In general, the more versions of a language targeted by a project, the > less efficient the project is. I'd say py3k is a great chance to > 'start clean' more or less: deprecate the python 2.x code and have > Django for python 3 be the official release. > > Python 3 makes it easy to get the right version to the right people. > There will be one distribution for python 2.x and one for python 3. > Django currently supports so many versions of python because so many > are in use. Python 3 is a great opportunity to trim this down, make > development easier, and still have something to give those who cannot > or will not upgrade to python 3. > > This is, after all, just my opinion. If you choose to go forward with > it, or if this gets accepted for Summer of Code, good luck with it, I > look forward to seeing what you produce. > > Sage > +1 Think about what KDE did when porting the codebase to Qt4. There was a translation tool released by TrollTech, but had exactly the same problems Sage has mentioned: you're code wasn't optimized for the new version of the toolkit. So, they decided to reimplemente a bunch of things, breaking the API and the ABI, but taking full advantage of the new toolkit. On the other hand, it's usually a tedious task, but and the end of the day, the benefits outweigh the hassle of rewriting some parts. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
