Anthony,
Thank you VERY much for reply.
Out of it I take that
(1) unless one is dealing with a pretty basic db, almost inevitably one
starts including web2py specific pieces that make sharing considerably more
complicated than just "from gluon import DAL, Field" :( In my case,
besides record versioning, validators etc. there's a trivial example - I
specify the path to the uploads folder as relative to "request.folder" :)
(2) As you say, unless there really is a very strong argument for stepping
outside the web2py environment, it really is just easier (and probably more
future proof) to extend the app to include the formerly standalone
functions (in a much extended modules directory) or, perhaps a separate
web2py app e.g. where the db is shared but where the user populations are
different. btw, how DOES one best share models between two web2py apps
Thanks again,
Jim
On Sunday, August 13, 2017 at 3:18:54 PM UTC-7, jim kaubisch wrote:
>
> I have good reason to want to create a database using a web2py app, but
> also access the db from a standalone app that does tons of data processing
> but basically does not need/want any user interaction
> The web2py app makes sure all data is consistent, supports the user in
> entering valid data, manages YouTube videos, and media maps on a website
> etc - lots of reasons for an interactive app.
> The standalone app does LOTS of data processing on the definitions created
> via the web2py app as well as other files.
> Its interface (for non-tech people) is simply click on "Import", followed
> by "Prepare" followed by "Deploy" - no UI wanted or needed (Logs are kept
> of what happened)
>
> I’ve looked, but so far have not found a complete explanation of how to
> access the same database both with web2py and standalone.
>
> 1. the book says;
>
> "
> The web2py DAL can be used in a non-web2py environment via
> 1. from gluon import DAL, Field
> 2. # also consider: from gluon.validators import *
> "
>
> YET in the standalone, shouldn’t it be
>
> from pydal import DAL, Field ?
>
> 2. Whichever I use, the db connection is made (good news) but,
> next problem I hit is that when I import my db model definition into
> the standalone, I get:
>
> NameError: "name 'T' is not defined"
> module body in dev.pyDAL_test.py at line 8
> import mfm_media_model
> module body in mfm_media_model.py at line 73
> Field('db_version', 'string' , label=T('DB Version') ,
> writable=False),
>
> ... and there would be others once I got past this one
> I have found no explanation of how to access the definitions of T and
> other helpers :(
>
> It would be really helpful to have even a simple template of how to
> implement access to a common database defined in web2py and standalone.
> I’ve looked and haven’t found one.
>
> 1. what to include in the model imports to define the standalone db access?
> from gluon? or from pydal? import DAL, Field? Or does it even matter?
>
> 2. What to include to import the same table definitions on both
> sides,
> including the helpers defined in the book for table
> definitions?
>
> 3. What about the question of “migrate_enabled”. presumably
> only set to True in one app? What are the gotchas, if any?
>
> 4. Is there anything else that’s required or, based on experience,
> wise to do include/exclude/avoid etc to make things work
>
> Apologies if I have missed someone's explanation or am not understanding
> something so obvious that I should be embarrassed to be asking
>
> Thanks,
> Jim
>
>
--
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 received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
