Submitted: http://code.google.com/p/web2py/issues/detail?id=1126
-Jim
On Tuesday, October 30, 2012 1:29:43 PM UTC-5, Massimo Di Pierro wrote:
>
> Please open a ticket about this. I will fix it in the next couple of days.
>
> On Tuesday, 30 October 2012 10:00:28 UTC-5, Jim S wrote:
>>
>> It seems then like it converts everything to lower case in the .table
>> file if you create it from scratch but if you run a fake_migrate then it
>> doesn't convert to lower case. Just appears (on the surface) that it is
>> inconsistent behavior. I've been a camel-case guy since my powerbuilder
>> days back in the 90s and it's one habit I've yet to break. And now I have
>> a pile of code that using it so I'm kinda stuck with this app. I know,
>> shame on me.
>>
>> Massimo, if you get the time could you weigh in on this?
>>
>> -Jim
>>
>> On Tuesday, October 30, 2012 9:50:33 AM UTC-5, Niphlod wrote:
>>>
>>> this is a question for Massimo, although ... we know your test is on
>>> ubuntu, but your production is on linux too ?
>>>
>>> PS: I see a comment like this in DAL
>>> # make sure all field names are lower case to avoid
>>> # migrations because of case cahnge
>>>
>>> so it's likely that those differencies won't trigger a migration.
>>> The "issue" is: where the system defined tables "with camelcase" the
>>> fields are accessible by camelcase pointers only and where it is all lower
>>> they are accessible only with lower names ?
>>> It would be an error to have a code working with
>>> db.district.includeinaraging
>>> in one instance and patch it to work on another instance to
>>> db.district.includeInArAging
>>>
>>> On Tuesday, October 30, 2012 3:30:07 PM UTC+1, Jim S wrote:
>>>>
>>>> Ok, now adding on to this situation.
>>>>
>>>> In my db.py I have the following defined:
>>>>
>>>> district = db.define_table('district',
>>>> Field('districtId', 'id', readable=False),
>>>> Field('district', length=5, required=True, unique=True),
>>>> Field('districtNumber', 'integer', required=True,
>>>> unique=True, label='District Number'),
>>>> Field('name', length=50, required=True, unique=True),
>>>> Field('salesmanId', db.auth_user, required=True,
>>>> label='District Manager'),
>>>> Field('includeInArAging', 'boolean', required=True,
>>>> label='Include in A/R Aging'),
>>>> Field('regionNumber', 'integer', label='Region Number'),
>>>> Field('manager',
>>>> compute=lambda id: '%s - %s' % (id.district,
>>>> db.auth_user(id.salesmanId).firstLast)),
>>>> format='%(manager)s')
>>>>
>>>> district.salesmanId.represent = db.auth_user.first_name
>>>> district.district.requires = [IS_NOT_EMPTY(),
>>>> IS_NOT_IN_DB(db, 'district.district'),
>>>> IS_UPPER()]
>>>> district.districtNumber.requires = [IS_NOT_EMPTY(),
>>>> IS_NOT_IN_DB(db, 'district.districtNumber')]
>>>> district.name.requires = [IS_NOT_EMPTY(),
>>>> IS_NOT_IN_DB(db, 'district.name')]
>>>> district.salesmanId.requires = IS_IN_DB(db, db.auth_user,
>>>> '%(lastFirst)s',
>>>> zero='.choose.')
>>>> district._plural = 'Districts'
>>>>
>>>> On my test machine I used a MySQL database hosted on an ubuntu box.
>>>>
>>>> On my production machine (where I ran the fake_migrate last week) I'm
>>>> using the same setup. Looking in the databases directory for my app on
>>>> each server I see that the field names are all lower case on my test
>>>> machine, but mixed case on my production machine (where the fake_migrate
>>>> was run). I've attached the two .table files. Is this an oversite on
>>>> web2py's part or something I have setup wrong that has caused the
>>>> case-confusion between my environments?
>>>>
>>>>
>>>> On Tue, Oct 23, 2012 at 5:12 PM, Niphlod <[email protected]> wrote:
>>>>
>>>>> yep, that can cause troubles.
>>>>> table files are named with an hash composed with the uri string, so
>>>>> you can import, let's say, table definitions for 10 dbs all in the same
>>>>> folder.
>>>>> If table files were created with an uri, and you try to auto_import
>>>>> with another uri, web2py will "search" for the "wrong" filenames.
>>>>>
>>>>>
>>>>> On Wednesday, October 24, 2012 12:08:25 AM UTC+2, Jim S wrote:
>>>>>
>>>>>> Found it. I had inconsistent case specified in my database name.
>>>>>> When running in web2py it was infoCenter2, when running outside, I had
>>>>>> infocenter2. Changing to infoCenter2 caused it to work correctly.
>>>>>>
>>>>>> Niphlod - Thanks for all the help. I truly appreciate it.
>>>>>>
>>>>>> -Jim
>>>>>>
>>>>>> On Tue, Oct 23, 2012 at 4:46 PM, Jim Steil <[email protected]> wrote:
>>>>>>
>>>>>>> Ok, I've got it now to where there are files in the databases
>>>>>>> directory, but still getting empty list for print db.tables
>>>>>>>
>>>>>>> -Jim
>>>>>>>
>>>>>>> On Tue, Oct 23, 2012 at 4:21 PM, Niphlod <[email protected]> wrote:
>>>>>>>
>>>>>>>> auto_import scans the table files for tables. That's the whole
>>>>>>>> point of not redefining models (because they are stored in table files
>>>>>>>> that
>>>>>>>> can be read).
>>>>>>>> Normal behaviour is:
>>>>>>>> DAL(..., migrate=True)
>>>>>>>> let it define tables, then
>>>>>>>> DAL(, migrate=False) #or migrate_enabled=False
>>>>>>>> so table files are never touched again, and can be imported.
>>>>>>>> PS: big_id isn't saved into table definitions, so you must specify
>>>>>>>> that parameter also outside (and it's safe I guess turning migrations
>>>>>>>> off
>>>>>>>> also for external access).
>>>>>>>>
>>>>>>>> To solve your problem, try one round of
>>>>>>>> DAL(..,migrate_enabled=False, fake_migrate_all=True)
>>>>>>>> fake_migrate_all will fake all table creations and generates the
>>>>>>>> relative .table files (of course you must be sure that your table
>>>>>>>> definitions are synced with your db structure)
>>>>>>>> From then on, you should be able to import them
>>>>>>>> DAL(...,migrate_enabled=False, big_id=True, auto_import=True,
>>>>>>>> folder='...')
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday, October 23, 2012 11:08:04 PM UTC+2, Jim S wrote:
>>>>>>>>
>>>>>>>>> It is empty.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Oct 23, 2012 at 4:01 PM, Niphlod <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> is your databases folder filled with the .table files relative to
>>>>>>>>>> the tables ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tuesday, October 23, 2012 10:57:04 PM UTC+2, Jim S wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi - I use MySQL for my database. In my production environment
>>>>>>>>>>> I'm specifying the following:
>>>>>>>>>>>
>>>>>>>>>>> db = DAL(infoCenterUtil.getDalString(), migrate=False,
>>>>>>>>>>> migrate_enabled=False, bigint_id=True)
>>>>>>>>>>>
>>>>>>>>>>> On my production machine I'm also trying to use the DAL outside
>>>>>>>>>>> of web2py with the following:
>>>>>>>>>>>
>>>>>>>>>>> import sys
>>>>>>>>>>> sys.path.append('c:/prod/web2py')
>>>>>>>>>>> from gluon import DAL, Field
>>>>>>>>>>> db = DAL('mysql://username:password@server/database',folder=
>>>>>>>>>>> 'c:/prod/web2py/applications/InfoCenter/databases', auto_import=
>>>>>>>>>>> True)
>>>>>>>>>>>
>>>>>>>>>>> print db.tables
>>>>>>>>>>>
>>>>>>>>>>> But, I get an empty list when I print db.tables. On my test
>>>>>>>>>>> machine where all of my auto-migrations happen, it works fine.
>>>>>>>>>>>
>>>>>>>>>>> Am I barking up the wrong tree in thinking that migration has
>>>>>>>>>>> something to do with my problem (print db.tables give empty list).
>>>>>>>>>>> If not,
>>>>>>>>>>> what am I doing wrong? I don't want auto-migrations on my
>>>>>>>>>>> production box.
>>>>>>>>>>> What is the proper way to have no migration on a machine, but
>>>>>>>>>>> allow for
>>>>>>>>>>> DAL outside of web2py?
>>>>>>>>>>>
>>>>>>>>>>> -Jim
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
--
