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 <nip...@gmail.com> 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 <ato....@gmail.com> 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 <nip...@gmail.com> 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 <nip...@gmail.com> 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
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>
>>>>
>>>>
>>>>
>>>
>>>
--
