> > Yup. The ORM goes out of its way to make safe strings. You can circumvent
> it
> > but that's naturally on your head. The Form classes also go a long way to
> do
> > the same. Forms go some distance further to make validation really simple
> > too.
> >
>
> Interesting, thanks. I did not know what ORM means but it seems to be
> some abstraction layer between the DB and the code, quite nice for not
> worrying about sanitation.
Object-Relational Mapper. It handles the DB completely. Writes your tables,
inputs your data, gets it back out and everything in between.
> Okay for this bit, I have three models in play. User (built into Django),
> > UserProfile (an extension of User, locked in with a foreign key) and
> > Company, referred to by UserProfile. In real DB terms there are 4 tables
> > there.
> >
> > Say I want to list users that are part of a given company. Easy:
> >
> > users = [u.user for u in UserProfile.objects.filter(company=company)]
> >
>
> So that's done right on the database abstraction layer? No SQL?
Correct.
> >
> > How about I want to filter another Model that has an FK on User, again,
> > given a company? Still super easy:
> >
> > data = AnotherModel.objects.filter(user__in = [u.user for u in
> > UserProfile.objects.filter(company=company)])
> >
> >
> > How about dynamic sorting? Here's how I exposed table-header based
> sorting
> > so you can sort by a named column and specify an order, with defaults if
> > nothing is specified:
> >
> > data = data.order_by('%s%s' % (request.GET.get('order', '-'),
> > request.GET.get('orderby', 'when')))
> >
>
>
> I don't think that it is safe to pass from the querystring directly
> into the database like that, unless there is some serious sanitation
> going on. I'd be wary, though. However, I get the point of the code
> and it does look tidy, though as I already know SQL I would probably
> prefer to query the DB directly.
This code is only used on pages that are locked to admin users, but as far
as I know, it is safe. All variables that get converted into SQL are
sanitized.
Users could break things (specifying a silly column name) but all that would
do would be throwing an exception saying the column didn't exist.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
