> entirely different issue here, thrown at database level rather than
> previous ones that were raised from web2py code
> this is a well-known gotcha
> http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#SQLite
>
Two things to note:
1) It's not the same case that
> Run the model for the *second* time. It works well.
>
> Run the model for the *third* time. Fails:
>
> *OperationalError: duplicate column name: f5*
>
>
entirely different issue here, thrown at database level rather than
previous ones that were raised from web2py code
this is a well-known
El viernes, 12 de diciembre de 2014 11:13:34 UTC-3, Niphlod escribió:
>
> nope, can't reproduce the issue. Something very weird is going on on your
> development system.
>
I tell you, I did the following: I uninstalled all ports (I have *FreeBSD
10.1*) and installed the minimum to run web2py
On Friday, December 12, 2014 4:40:59 PM UTC+1, Tom Øyvind Hogstad wrote:
>
> I have probably the same issue.
> After it popped up and I couldn't resolve it I have manually added the
> fields to postgre.
>
> As I understand fake migrate it will regenerate the data needed for
> migrate.
>
nope.
I have probably the same issue.
After it popped up and I couldn't resolve it I have manually added the
fields to postgre.
As I understand fake migrate it will regenerate the data needed for migrate.
So after a fake migrate adding a field and the normal migrate should work
out great.
It dosen't
nope, can't reproduce the issue. Something very weird is going on on your
development system.
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You receive
If instead of removing the field, create a new one, so does
db.define_table('mi_tabla',
Field('f1', 'integer'),
#Field('f2', 'integer'),
Field('f3', 'integer'),
Field('f4', 'integer'),
Field('f5', 'integer'),
migrate='mi_tabla.table'
)
First run, works fine
A few days ago I reported this [1] fault.
I understand that failure, to happen to everyone, had reported long ago. I
wonder if maybe I have something in my environment that causes these
failures occur as illogical.
[1] https://code.google.com/p/web2py/issues/detail?id=2023&start=100
--
Reso
El jueves, 11 de diciembre de 2014 16:52:48 UTC-3, Niphlod escribió:
>
>
>> ProgrammingError: column "f2" of relation "mi_tabla" does not exist
>>
>>
> Once again.. this exception is raised when some piece of code
> references f2 from mi_tabla. I'd be happy to find that piece of code for
>
>
>
> ProgrammingError: column "f2" of relation "mi_tabla" does not exist
>
>
Once again.. this exception is raised when some piece of code
references f2 from mi_tabla. I'd be happy to find that piece of code for
you if you pack an app that reproduces the issue.
>
--
Resources:
- http:
El miércoles, 10 de diciembre de 2014 16:54:17 UTC-3, Niphlod escribió:
>
> BTW, what you are experiencing is totally predictable, but you're "barking
> at the wrong tree".
>
> now:
> migrate=True, fake_migrate=False
>
I start with a database empty.
db = DAL('postgres://usr:psw@localhost/siste
BTW, what you are experiencing is totally predictable, but you're "barking
at the wrong tree".
now:
migrate=True, fake_migrate=False
db.define_table('mi_tabla',
Field('f1', 'integer'),
Field('f2', 'integer'),
Field('f3', 'integer'),
Field('f4', 'integer'),
migrate='mi_t
There's some confusion going on, to make sure everything is correct, follow
these steps.
1. Put your models exactly has the database tables are.
2. Do a fake migrate.
3. Remove fake migrate and set migrate=True
4. Do the changes you need in your model.
--
Resources:
- http://web2py.com
- http:
if you see the end of sql.log file. On each request try to delete the field.
[What I understand is that the definition of the table is stored in
/databases/mi_tabla.table]
timestamp: 2014-12-10T12:38:51.732946
ALTER TABLE mi_tabla DROP COLUMN f2;
timestamp: 2014-12-10T13:25:21.465148
ALTER TABLE
El miércoles, 10 de diciembre de 2014 13:11:27 UTC-3, Leonel Câmara
escribió:
>
> In this instance you don't want to fake_migrate you actually want to have
> migrate=True. Fake migrate is for when the tables defined in the models
> already reflect the tables that are really in the database and
In this instance you don't want to fake_migrate you actually want to have
migrate=True. Fake migrate is for when the tables defined in the models
already reflect the tables that are really in the database and you just
want to generate the table files.
--
Resources:
- http://web2py.com
- http:/
16 matches
Mail list logo
