Russ,
>As for templates - they don't ever use the CamelCase name. They
>exclusively use the model names, and there's no 'raw query' equivalent
>for templates.
This is the problem that is presenting the possible bug. I have to use
{{ m.SomeField }} in my template rather than {{ m.somefield }} as you
suggest should always be the case.
I am using a raw query because I couldn't for the life of me get the
related object query for Checkin.objects.filter(...) to work.
Sometimes I actually find the ORM more confusing than raw sql ;)
Greg
On May 15, 5:19 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Fri, May 14, 2010 at 5:29 AM, geraldcor <gregco...@gmail.com> wrote:
> > Hello,
>
> > Some background first. I am working with a legacy database that is not
> > only legacy, it is legacy Microsoft access so there is some hacking
> > going on. I am accessing a MySQL backend and my models are set up to
> > use the existing tables/field names. When I use regular old ORM
> > queries, Everything works as normal and I can access fields using a
> > for loop and iterator.fieldname.
>
> > In order to access the joined fields between two tables, I had to
> > resort to themanager.rawsyntax. Here is my syntax
>
> > confirm_data = Checkin.objects.raw('SELECT * FROM Checkin JOIN
> > CheckinTests ON Checkin.SampleID = CheckinTests.SampleID WHERE
> > Checkin.DateArrived = %s AND Checkin.Company = %s', [date_arrived,
> > company_name])
>
> > 1. I have to use the legacy db table names and field names i.e.
> > CamelCase names
> > 2. Once the query is executed and either in the shell or a template,
> > when I iterate over the queryset for the main table I can use
> > c.fieldname but for the joined table I have to use c.FieldName. It's
> > as if the joined table isn't returning the model names but the table
> > names from MySQL. Is this a bug? It's kindof annoying to have to use
> > two different syntaxes in my templates.
>
> It's hard to tell if this is a bug, but my initial reaction is
> probably not -- although that is moderated by the fact that I'm a
> little hazy on what you are describing. This is mostly because I'm
> getting confused over which bits are MySQL, which bits are Access,
> which bits are template code, and why joining matters at all.
>
> There are two completely independent naming domains in use here
> 1) The attributes on a Django model
> 2) The field names on the SQL database.
>
> By way of example, if you have the following model:
>
> class MyModel(Model):
> fieldname = CharField(max_length=100, db_colum='FieldName')
>
> This defines a Django model with a field called 'fieldname', backed by
> a database column named 'FieldName'. You can create instances and
> assign values using the lowercased name:
>
> >>> m = MyModel()
> >>> m.fieldname = 'ham'
> >>> m.save()
>
> and the underlying SQL that is executed will use the db_column:
>
> SELECT FieldName ... FROM myapp_mymodel WHERE ...
>
> If you're issuing raw queries, then yes - you will need to deal with
> the CamelCase names, but that's because you're manually issuing SQL.
> However, if your queries are as simple as the example you provide, you
> shouldn't even need to use raw queries - you should be able to do a
> simple MyModel.objects.filter(...) call, and not worry about the
> column names at all.
>
> As for templates - they don't ever use the CamelCase name. They
> exclusively use the model names, and there's no 'raw query' equivalent
> for templates.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group
> athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
