The new DAL is a priority and we are close to completion (will need testing). But the first version will just be a rewrite of the current one. New features will come later. When the new DAL is out we may need you help to this done.
On Jan 6, 3:43 pm, Michael Toomim <[email protected]> wrote: > So I should just wait? > > On Jan 6, 8:26 am, mdipierro <[email protected]> wrote: > > > You are correct and that is the future. It is different for every db. > > The new DAL will have hooks to implement it. > > > Massimo > > > On Jan 6, 3:14 am, Michael Toomim <[email protected]> wrote: > > > > Here's what I propose: > > > > In define_table, at this point: > > > > if migrate: > > > sql_locker.acquire() > > > try: > > > t._create(migrate=migrate, fake_migrate=fake_migrate) > > > finally: > > > sql_locker.release() > > > > At the end, it can read the database schema and see if it contains all > > > the columns needed in the cPickle .table file. If not, it can output > > > something like "Sorry, database table %s needs column %s to look like > > > %s, this needs a manual fix". > > > > Is this right? I'm not sure how to read a database table schema > > > programmatically. Is this different for each db? Hopefully it's at > > > least easy for postgresql. > > > > On Nov 18 2009, 11:46 am, mdipierro <[email protected]> wrote: > > > > > Yes, I would. > > > > > On Nov 18, 2:03 am,toomim<[email protected]> wrote: > > > > > > Thanks! Would you accept a patch that makes the error messages more > > > > > obvious in these situations where you need to manually edit the > > > > > tables? > > > > > > I think ROR and Django's approaches to migrations (fully-specifying > > > > > deltas vs. maintaining static schemas) are both more burdensome than > > > > > web2py's system of "semi-automatic for most changes (adding columns & > > > > > tables) but manual for major changes". But the "manual for major > > > > > changes" part needs better error messages with suggestions for how to > > > > > proceed. > > > > > > On Nov 14, 8:04 pm, mdipierro <[email protected]> wrote: > > > > > > > You are changing a "text" column (Field) into an "ineteger" column. > > > > > > My > > > > > > changing the type web2py assumes you want to keep the data and yet > > > > > > it > > > > > > cannot convert "text" to "integert". You have to do the migration in > > > > > > two steps: 1) remove the column (comment it and run appadmin) 2) add > > > > > > the column again with the new type. In this case web2py understands > > > > > > you do not want to keep the data and will not attempt to do it. > > > > > > > On Nov 14, 7:08 pm,toomim<[email protected]> wrote: > > > > > > > > I routinely run into migration problems. I suspect this happens > > > > > > > when I > > > > > > > change a column's datatype, or when I remove a table from db.py > > > > > > > and > > > > > > > then later make a new table with the same name as the old one. > > > > > > > > In these situations, the migrations get messed up and I get > > > > > > > stacktraces in sql.py with errors like: > > > > > > > > ProgrammingError: column "study__tmp" is of type integer but > > > > > > > expression is of type text > > > > > > > LINE 1: UPDATE actions SET study__tmp=study; > > > > > > > ^ > > > > > > > HINT: You will need to rewrite or cast the expression. > > > > > > > > How can I migrate in these situations? > > > > > > > > As an aside, I love the automatic migrations when they work, but I > > > > > > > don't mind writing sql to fix the underlying database when they > > > > > > > don't. > > > > > > > Could web2py just tell me what schema it expects, let me fix the > > > > > > > database, and then let me say "OK web2py, the database is ready > > > > > > > to go!" > >
-- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
