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]
> <javascript:>>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
>>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>
>>
>>
>>
>
>
--
