Hi Russ, I have done as you suggested and the solution (If I didn't mess things up) was actually quite simple indeed. We are using pyodbc and django-pyodbc. I have submitted my change to the django-pyodbc guys, for them to have a look.
If they actually implement this it will be my first contribution to an open source project and my parents will be very proud. So thanks for your time and your reaction. Kind regards, Erik On 12 jun, 01:19, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Mon, Jun 11, 2012 at 4:26 PM, rico_suave <erik.oosterw...@gmail.com> wrote: > > Hi All, > > > We (as a company) are relatively new to Django and currently implementing a > > system where we use inspectdb to use an existing MSSQL 2005 database from > > within Django. > > We have encountered different problems with the ORM part of the application > > in combination with MSSQL, most of which we have been able to solve by > > writing a small Python script that takes the output from dbinspect and does > > some regex to generate a more useful (for us) file. > > > However, there is now one thing our script is unable to solve (or at least > > it would be relatively hard to solve it in a script.). I was hoping someone > > has some experience with this and can suggest a simple solution; > > > The database has some varchar([n]) fields, which inspectdb translates into > > textfield types, with no max_length. These fields have defined lengths, so a > > charfield with a max_length would be preferable.The strange thing is > > inspectdb does the right thing for nvarchar([n]) fields, it's just the > > varchar([n]) fields that fail. > > > Ofcourse your first suggestion might be to just add the max_length > > properties and change the field type in the outputfile, but we have opted > > for a system where we have a class file that has all of the database models > > and that inherits from the output of inspectdb. This allows us to run > > inspectdb as soon as something in the database-structure changes, but to > > keep our models,and modifications to or models, as they are. > > The flipside is that in our inherited models class, we can only add methods > > and properties, we can't override existing ones. So this problem is not > > fixable in our own models class file. > > > Any suggestions will be much appreciated, > > Well, my first suggestion is to just manually add the max_length and > change the field type in the output file… :-) > > But seriously -- what you seem to be missing is that this is an open > source tool. In particular, since you're dealing with MSSQL, you're > dealing with an open source extension (your MSSQL binding) to an open > source tool (Django). > > So you've found a bug. You know what the solution is? You fix the bug! > > MSSQL isn't officially supported by Django itself -- MSSQL support is > handled by a couple of different third party plugin projects. You > haven't mentioned which one you're using, so I can't point you at any > specific forum or person -- but the basic solution will always be the > same. Find their ticket database and search it for a report of a > similar problem. Check the tip of their development source tree to see > if the problem has been resolved since the last release. Check on > their mailing list to see if anyone else has a similar problem. If > nobody has a similar problem, pull apart the source code and work out > what is going wrong. And when you've figured out the problem, submit a > patch. > > If you don't feel confident fixing the problem yourself, then the > other option is to get someone else to fix the problem for you. Again, > because you haven't said which MSSQL adapter you're using, I can't > offer any specific guidance -- the maintainers may have the spare > cycles to look into the problem on your behalf, or you may have to pay > them for their time. > > What I can tell you is that inspectdb isn't actually that complicated, > so although "fix it yourself" may sound daunting, it really shouldn't > be. inspectdb uses the database's native introspection mechanism to > retrieve a description of a table, and then uses some fairly simple > rules to convert that definition into a Django model definition. The > code will all be contained in a single class called > DatabaseIntrospection, probably contained in a file called > introspection.py. As a guide, the introspection module for PostgreSQL > is 88 lines of code; Oracle is 117 > (django/db/backends/oracle/introspection.py if you want to see the > built-in implementations) > > 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-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.
