yes I am working with legacy data transferred from FileMaker. That's
why I put in the meta table so the "real" import will work, once it's
ready for production.
There are actually 5 "look up" tables as I call them:
lu_country <-- any countries already selected from the existing data.
the main table papers_admin has just the ID stored for each country.
the remaining tables
lu_paper_content_era
lu_paper_content_genus
lu_paper_content_region
lu_paper_content_topic
Don't really have any data from the source but I set all to 0 in the
main table as this corresponds with a "nothing selected" value in the
look-up table.
So, there are no nulls in the main table for any of these look-up
tables.
And, from what you're saying, Django is smart enough to grab the text
component in the UI and store the ID in the actual table, which is
very cool -- are you sure that's true? I don't have to tell Django
anything? What if there's several columns for an ID - what gets
picked for display? Confusion reigns....
Anyhow, I have worked to make sure my db design is expected to only
store the ID selected from a list, not the text, true to the heart of
a RDBMS.
All of these fields are INTEGER, not null as well.
But there are weird little gremlins running around!
I thought "well, let's just rename the main table to something that
doesn't exist yet in syncdb to see what happens" and renamed the model
papers_admin to papers_admin_W_FK -- sycndb just ignored my change.
of course I saved, but re-edited the Models.py file to
papers_admin_Uno_Mas and again syncdb just refuses to notice my
changes.
To make matters worse, the results for inspectdb doesn't even list the
existing tables correctly (papers_admin is now papersadmin), and the
foreign key fields don't exist. results from SQL papers_app do show
most of the fields from the Model but some of the fields that should
have FK set do and some don't:
`PaperContent_Era_id` integer NOT NULL, <-- where be yon
REFERENCES?
`PaperContent_Genus_id` integer NOT NULL REFERENCES
`lu_paper_content_genus` (`id`),
`PaperContent_Region_id` integer NOT NULL REFERENCES
`lu_paper_content_region` (`id`),
`PaperContent_Topic_id` integer NOT NULL, <-- where be yon
REFERENCES?
I understand Django will append _ID for FK set fields so I can
understand that these fields may not be explicitly listed in Models.py
but I do have them as columns in the parent table.
And, as I've always noticed, syncdb ALWAYS sets all columns to NOT
NULL regardless of what's in the models file, which is a bit
annoying. All of this doesn't help of course. I don't know if
there's any issues with MySQL 5.1, say...
All very weird... I guess i could break this down to one table and one
look-up table first as it's hard to tell what's going on, but my hope
was there's some simple idiocy I am committing.
It's a bit frustrating because if I could get this one last issue
resolved I have gone quite a ways towards finishing this little job.
This is my very first Django project, BTW.
Thanks for all your help!
On Apr 13, 9:26 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 13, 2008 at 9:48 PM, steve skelton <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > thanks - I've tried it both ways and with __str__ get the error
>
> > __str__ returned non-string (type NoneType).
>
> That's odd...
>
>
>
> > the top-level error dump is
>
> > Request Method: GET
> > Request URL: http://localhost:8000/admin/papers_admin/paper/35/
> > Exception Type: TypeError
> > Exception Value: __str__ returned non-string (type NoneType)
> > Exception Location: C:\Python25\lib\site-packages\django\db\models
> > \fields\__init__.py in get_choices, line 302
>
> > all the models where I apply
>
> > __str__ are of the form
>
> > class LuPaperContentRegion(models.Model):
> > paper_content_region = models.CharField(maxlength=150)
>
> > def __str__(self):
> > return self.paper_content_region
>
> > class Meta:
> > db_table='lu_paper_content_region'
>
> Are you building these models from scratch with a new database or working
> with a pre-existing database? The fact you are specifying db_table in Meta
> makes me think maybe you are trying to map models over an already-existing
> table? Which can be done, but if the Django model definition isn't
> correctly mapping the real table it might lead to problems.
>
> Right now as that model is defined to Django, the Django admin would not
> allow paper_content_region to be set to null, which is the only way I can
> think of that your __str__() would return None. So I'm confused how you are
> getting this error.
>
> list to the FK model as
>
>
>
> > Country = models.ForeignKey(LuCountry)
>
> > since this would be a link to the LuCountry table by the ID and my
> > expectation is this might display the ID in the linked table, not a
> > string so perhaps this may be the source of the problem -- but that is
> > just a guess.
>
> Now, the target for the ForeignKey here is LuCountry, which we haven't seen
> before. Is this the one having a problem or is it the one with
> LuPaperContentRegion? If its LuCountry that's having the problem that's the
> model we need to see.
>
> To back up to a conceptual level, what the admin is trying to do is build a
> list of all possible targets for this foreign key, in human-readable form,
> for the select drop-down box. Under the covers it will know the primary key
> ID of each of the elements in the list, and that is what will be stored in
> the table when you select one, but to make it easier to select the right one
> it is going to present the user a friendly list. So it's essentially going
> to select all the elements in the target table and call your __str__
> function for each one. (There is an option to turn this off and force the
> user to enter raw IDs for cases where your tables are too large for this
> approach to work well, but you're not using that here.)
>
> So, if you are working with a pre-existing table, any null values in fields
> you are returning with __str__ could be causing this problem. And that's
> about the only wild guess I have right now to explain what you are seeing.
>
> Karen
>
> > Thanks for your response - hopefully there is a simple thing I am not
> > getting.
>
> > On Apr 13, 8:35 pm, Michael <[EMAIL PROTECTED]> wrote:
> > > Try changing __unicode__ to __str__. The unicode merge was after .96 and
> > > therefore it isn't looking for __unicode__ to define the name of the
> > field.
>
> > > Hope that helps,
>
> > > Michael
>
> > > On Sun, Apr 13, 2008 at 9:28 PM, steve skelton <
> > [EMAIL PROTECTED]>
> > > wrote:
>
> > > > sorry I forgot to specify - am using 0.96.1 (django) and MySQL 5.0.51a
> > > > (server) and 5.1.11 (client) and my local install is on Vista laptop
> > > > with Apache and PHP also installed.
>
> > > > On Apr 13, 8:24 pm, steve skelton <[EMAIL PROTECTED]> wrote:
> > > > > Trying to get admin on my system to load values based on related
> > > > > tables on db. I have set the FK on the papers table to tie with the
> > > > > PK of each look-up table and set models like so:
>
> > > > > class LuPaperContentEra(models.Model):
> > > > > paper_content_era = models.CharField(blank=True, maxlength=150)
>
> > > > > def __unicode__(self):
> > > > > return self.paper_content_era
>
> > > > > class Meta:
> > > > > db_table='lu_paper_content_era'
>
> > > > > The main table, which should contain drop-downs for things like the
> > > > > model/table above, has things like:
>
> > > > > class Paper(models.Model):
> > > > > ... many fields defined
> > > > > PaperContent_Era = models.ForeignKey(LuPaperContentEra)
> > > > > ... more fields defined
>
> > > > > class Meta:
> > > > > db_table='papers_admin'
>
> > > > > class Admin:
> > > > > list_display=('id','FirstName','LastName','Institution')
> > > > > search_fields=['LastName']
>
> > > > > However, Admin displays the drop-down as
>
> > > > > LuPaperContactEra object, NOT the actual human-readable value list.
>
> > > > > I feel I am probably close to getting this to work but can't seem to
> > > > > find the right direction in which to be "nudged".
>
> > > > > Thanks!
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
