How is it a problem? We can have the ORM handle specific dbms in a specific way. This isn't a problem, it's merely a translation. The *only* problem, is gathering up all the commands necessary for the different dbms. And I don't see how this could be done with GAE (then again I have *zero* experience with GAE so may be it is possible?)
On May 7, 9:21 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
