that's the problem.
On May 7, 12:39 am, Michal Jursa <mic...@jursa.cz> wrote:
> Abbsolutely not, SHOW TABLES is MYSQL specific command. Postgres
> implements the same funcionality with SELECT * FROM
> pg_catalog.pg_tables, Oracle makes the same magic with SELECT TABLE_NAME
> FROM USER_TABLES etc etc...
>
> Michal
>
> mdipierro wrote:
> > hmmm. This may be a good idea. Is SHOW standard SQL? I am not sure all
> > backends support it.
>
> > On May 6, 7:05 pm, TheDude <officed...@gmail.com> wrote:
> >> Massimo, may I propose a solution here? It would require a lot of
> >> work, but if it were done I think it'd destroy the competition of
> >> other ORMs :P Anyways, have the ORM/DAL catch any errors presented
> >> (not sure if this is possible with GAE). If it *does* catch an error,
> >> see which number, have python look up what to do with tht number (e.g.
> >> Is a table missing? A field? etc). then it will perform the necessary
> >> query SHOW TABLES; SHOW FIELDS FROM [table]; etc. and then re-build
> >> the .table file. So it'll constantly load locally until it finds an
> >> error. Of course there should also be some kind of throttling
> >> mechanism, where if it does see an error but can find a solution, then
> >> it'll makr that in like a global.orm.table file so that the next time
> >> the error is catched for the same table/field, it would execute any
> >> SQL queries and it'll still submit the support ticket of course (may
> >> be a support ticket for when DAL figures out the DB on its own as
> >> well). I know I know, this is a very complicated system, but I mean,
> >> if web2py can completely move the thought process of having to
> >> constantly fight with the DB and the app, it would be an awesome
> >> feature. :) I know that I'm just dreaming, but a boy can wish can't
> >> hey? :'')
>
> >> On May 5, 4:10 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
>
> >>> someone looked into this, tried some time back ... emulating the kinds of
> >>> things that sqlalchamy does; I think he had limited success; not sure I
> >>> recall what the summary was.
> >>> On Tue, May 5, 2009 at 2:50 PM, Hans
> >>> <johann.scheibelho...@easytouch-edv.com
> >>>> wrote:
> >>>> Symlinking the app/database folder would work in environments with up
> >>>> to one application server.
> >>>> Unfortunately also I don't know how to query the database table
> >>>> structure in all web2py supported databases. But, maybe, we have some
> >>>> experts for one or the other supported database on the forum and
> >>>> willing to contribute!?
> >>>> On May 5, 9:14 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> >>>>> I agree and it does not have to me. The current system does not limit
> >>>>> that. It only limits the fact that one app should do migrations. If
> >>>>> more than one app may do migrations just symlink the database folder.
> >>>>> Massimo
> >>>>> On May 5, 2:09 pm, Hans <johann.scheibelho...@easytouch-edv.com>
> >>>>> wrote:
> >>>>>> IMO one more thing to consider is that a database is not necessarily
> >>>>>> exclusively owned by one application. I would even go further and say
> >>>>>> default should be a database is NOT exclusively owned by one app and
> >>>>>> also not by one framework.
> >>>>>> Currently the problem arises if the .table files of one web2py app
> >>>>>> (stored in app/database folder) get out of sync with the database.
> >>>>>> To get the .table files of a web2py app out of sync with a central
> >>>>>> database is easy. Just have a 2nd app create a table which is also
> >>>>>> used by app #1. If app #1 does not set 'migrate=False', including
> >>>>>> auth.define_table(migrate=False), this app will not work any more.
> >>>>>> Same for app #3, #4, ... Those apps can also be non web2py apps which
> >>>>>> automatically create non existing tables, like web2py does it by
> >>>>>> default.
> >>>>>> my 2 eurocents
> >>>>>> Hans
> >>>>>> I understand that throwing the default assumption 'the application
> >>>>>> owns the database tab
> >>>>>> On May 5, 6:13 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> >>>>>>> Yes or perhaps a repair.py script.
> >>>>>>> Massimo
> >>>>>>> On May 5, 10:24 am, Yarko Tymciurak <yark...@gmail.com> wrote:
> >>>>>>>> On Tue, May 5, 2009 at 9:25 AM, mdipierro <mdipie...@cs.depaul.edu>
> >>>> wrote:
> >>>>>>>> ....
> >>>>>>>>> The only problems I can see would arise if:
> >>>>>>>>> - You delete databases/*.table but the database is still there
> >>>>>>>>> (updates do not cause this). Bad luck. One should not delete
> >>>> files, or
> >>>>>>>>> at least make a backup.
> >>>>>>>> Maybe at some point we can address this w/ some mercurial checkin
> >>>> of such
> >>>>>>>> important files on a running system...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
