happy to hear that... of course lazy_tables "postpone" the eventual
migration at the first attempt of accessing it....
On Thursday, December 6, 2012 2:47:48 AM UTC+1, Joe Barnhart wrote:
>
> Wait! I figured it out! When lazy_tables=True the column structure is
> migrated only when the table is built. Duh! I switched lazy_tables=False
> and it migrated table 2 as you experienced.
>
> Whew! I thought I was going crazy(er) for awhile!
>
> -- Joe B.
>
> On Wednesday, December 5, 2012 12:25:51 PM UTC-8, Niphlod wrote:
>>
>> thx. Just checked with stable and development, columns get migrated and a
>> costraint is applied both to the parent and the child table
>>
>> On Wednesday, December 5, 2012 7:58:30 PM UTC+1, Joe Barnhart wrote:
>>>
>>> Ok, here is the setup. I have a table defined:
>>>
>>>
>>> db.define_table("xxxxxxx",
>>> Field("lastname","string",length=50,label="Last name",requires=
>>> IS_NOT_EMPTY() ),
>>> Field("firstname","string",length=50,label="First name",requires=
>>> IS_NOT_EMPTY() ),
>>> Field("middlename","string",length=50,label="Middle name" ),
>>> Field("prefname","string",length=50,label="Nickname"),
>>> Field("birth","date",label="Birth date",requires=IS_DATE()),
>>> Field("ussnum","string",length=14,unique=True),
>>> . . .
>>>
>>>
>>>
>>> This table is used in a later table definition...
>>>
>>>
>>> db.define_table("yyyyyyy", db.xxxxxxx,
>>> Field("regstate","string",length=10,label="Registration state",
>>> readable=False,writable=False),
>>> Field("processdate","date",label="Process date",readable=False,
>>> writable=False),
>>> . . .
>>>
>>>
>>> I added the "unique=True" constraint to the column highlighted in table
>>> xxxxxxx and then opened a page to cause the web2py table migration to take
>>> place. I examined both table xxxxxxx and yyyyyyy with the Postgres tools
>>> and found that table xxxxxxx had the column constraint added but table
>>> yyyyyyy did not.
>>>
>>> -- Joe B.
>>>
>>>
>>>
>>> On Wednesday, December 5, 2012 3:20:55 AM UTC-8, Niphlod wrote:
>>>>
>>>> uhm: are you sure that adding unique=True gets the created index also
>>>> in the parent table ? I think that the unique is enforced only on creation
>>>> and not in migration (but the requires=IS_IN_DB() gets added anyway). In
>>>> any case, what are you observing? (in other words, post a model and a
>>>> controller to reproduce the issue)
>>>>
>>>> On Wednesday, December 5, 2012 12:08:03 PM UTC+1, Joe Barnhart wrote:
>>>>>
>>>>> This is probably old news, but I noticed this evening that altering a
>>>>> table which is used as a "parent" by another does not cause its child
>>>>> table
>>>>> to be altered.
>>>>>
>>>>> I have a table which I added a "unique=True" constraint on this
>>>>> evening and its child table did not get the added constraint when web2py
>>>>> did its migration.
>>>>>
>>>>> (I admit to being lazy and not searching to see if this has been
>>>>> reported before. Google groups are pretty hard to search for something
>>>>> this specific.)
>>>>>
>>>>> -- Joe B.
>>>>>
>>>>>
--
