not that I recommend this but you can do
def index():
execfile(os.path.join(request.folder,'models','mymodel.py'))
...
return locals()
The execfile can be outside.
I do not think it is a good idea because it would not take advantage
of pyc caching, bytecode compilation would break an
How about we provide a script that fixes that automatically?
models//.py -> models/_/py
is anybody else using model subfolder?
Massimo
On May 1, 8:09 pm, Thadeus Burgess wrote:
> Nononononononono
>
> This breaks the way it currently works. I have multile web2py apps that take
> advantage o
yes. You would not be saving memory as much as you would be saving
time.
On May 1, 9:50 pm, pbreit wrote:
> Am I understanding correctly that we could save memory by not loading all
> models on all page views? That seems like a reasonable objective.
Would there be an approach to this using some sort of loading scheme? The
directory approach seems like it could get cumbersome as well as be
problematic for models that are used in multiple controllers.
It works for me but under the hood there were a few changes.
We need to make sure that indeed we did not break anything and in
particular we did not break backward compatibility.
Some people, like Thadeus, have been using subfolders already. I do
not think that should be considered a backward com
It is not the new feature that may break something is it the
implementation. For example I had to rewrite a lot of code to make
sure modules in applications bytecode compiled "before" this new
feature still run at all. I have not done extensive tests that this is
correct (although I think so).
On
If you can use import it is a module, not a model. A model in web2py
must be executed - by definition.
On May 2, 12:43 am, pbreit wrote:
> This screams "import" to me.
>
> === default.py ===
> from myapp.models import db
>
> def index()
> ...
This is pretty awesome and will be very helpful with large,
enterprise applications, as well as applications that do many things that
are not all related. I wonder if we could take this a bit further though...
Plugins, for example, extract themselves to the various locations (models,
controller
This was discussed long ago...
Here is the problem. Plugins are a packaging mechanism.
Now an app has models/views/controllers/etc and a plugin can be "any
subset of an app".
If you relegate plugins into a subfolder called plugins than they
cannot be "any subset of an app". For example they canno
I just mean that it seems like this is a case where normal Python or
Pyton-like "importing" would make the most sense. So instead of coming up
with an elaborate scheme of model filenames and directory structures, you
could simply specify which models should get loaded by which controllers.
That will go away. Web2py already has a thread local singleton and it
will be used in future version to allow any module to do something
like:
from web2py import g
g.request
g.response
g.db
etc.
without passing globals()
On May 2, 3:30 pm, Bruno Rocha wrote:
> On Mon, May 2, 2011 at 5:22 PM, A
One issue we need to solve is appadmin. With the experimental stuff in
trunk, appadmin would not see lots of models.
Now sure how to solve this because I would not know how to determine
order of execution. Idea?
Massimo
On May 2, 6:09 pm, Martín Mulone wrote:
> Nice,but anthony is right when th
Nononononononono
This breaks the way it currently works. I have multile web2py apps that take
advantage of subfolders for models to group them in the way they should
execute.
This feature means i could NEVER upgrade my apps again.
On May 1, 2011 7:44 PM, "Massimo Di Pierro"
wrote:
> not that
Thadeus, this is an improvement for code organization and less use of
memory, I dont think it breaks compatibility. because there are no place in
actual documentation where you can find info about using subfolders. Massimo
said sometime ago that subfolders was "reserved" for future implementation.
Am I understanding correctly that we could save memory by not loading all
models on all page views? That seems like a reasonable objective.
I tested here, I created designs seen around the controller and also in
specific actions,and everything is quiet, working perfectly.
_
*Gilson Filho*
*Web Developer
http://gilsondev.com*
2011/5/2 pbreit
> Would there be an approach to this using some
Yes, lets say we have this app:
models/general.py # this model and all models in root folder is always
executed
models/default/something.py # this model and all on the same folder is only
executed when http:///app/default/* is requested
models/default/index/something.py # this model and all
Will need more tests or already is scheduled to play for production?
_
*Gilson Filho*
*Web Developer
http://gilsondev.com*
2011/5/2 Bruno Rocha
> Yes, lets say we have this app:
>
> models/general.py # this model and all models in root folder is alwa
Also, I think it is a benefit when working with 'web2py_components' that
today on every ajax call executes all models again on a separate request, in
a modular page built with 5 components we are going to have all models
loaded for 5 different requests.
This new approach is a memory saver if you
On Mon, May 2, 2011 at 12:04 AM, pbreit wrote:
> Would there be an approach to this using some sort of loading scheme? The
> directory approach seems like it could get cumbersome as well as be
> problematic for models that are used in multiple controllers.
I agree that some kind of router is a
Breaking with other versions will be difficult, because they will be using
templates tothe application level. With that would not cause any bugs.
Perhaps what needs to betested is the automatic update of the framework.
_
*Gilson Filho*
*Web Developer
http
On Mon, May 2, 2011 at 12:25 AM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:
> It works for me but under the hood there were a few changes.
>
> We need to make sure that indeed we did not break anything and in
> particular we did not break backward compatibility.
For me this does not
Except that I don't have any models that are specific to components. Will I
need to duplicate model files into each folder corresponding to the
controllers that use them? My models seem to be fairly cross-controller so
I'm not sure how I will use this approach.
This screams "import" to me.
=== default.py ===
from myapp.models import db
def index()
...
On Mon, May 2, 2011 at 2:38 AM, pbreit wrote:
> Except that I don't have any models that are specific to components. Will I
> need to duplicate model files into each folder corresponding to the
> controllers that use them?
No, just leave all your models on root folder and everything will run as
Right, but I get no benefit then.
On Monday, May 2, 2011 10:33:59 AM UTC-4, pbreit wrote:
>
> Right, but I get no benefit then.
If you've got models that are needed by multiple controllers, then there's
no benefit to be had -- all your models will have to be run on every request
anyway. The benefit comes if you've got some mo
routed solution is the next step, depending on the application the better
way is using modules instead of models.
--
Bruno Rocha
[ About me: http://zerp.ly/rochacbruno ]
> If you've got models that are needed by multiple controllers, then there's
> no benefit to be had -- all your models will ha
Is routing the only other solution or would an "import" or import-like
approach be feasible?
On Mon, May 2, 2011 at 2:14 PM, pbreit wrote:
> Is routing the only other solution or would an "import" or import-like
> approach be feasible?
models needs to be executed not imported, I think would be kind of helper
for doing that, like:
def index():
RUN_MODEL('test','index')
2011/5/2 Bruno Rocha :
> On Mon, May 2, 2011 at 2:14 PM, pbreit wrote:
>>
>> Is routing the only other solution or would an "import" or import-like
>> approach be feasible?
>
> models needs to be executed not imported, I think would be kind of helper
> for doing that, like:
> def index():
> RU
On Mon, May 2, 2011 at 4:57 PM, danto wrote:
> what would be the difference from using import module?
The main difference is that models executed implicit knows web2py
environment as session, request, response etc. and that is easiest to define
some things in models.
modules does not have this
On Monday, May 2, 2011 4:12:25 PM UTC-4, rochacbruno wrote:
>
>
> I am not sure if we can have classes in modules to define tables and them
> pass DAL, response, request etc.. I need to test this approach.
>
That's how Auth and Crud work, no?
On Mon, May 2, 2011 at 5:22 PM, Anthony wrote:
> On Monday, May 2, 2011 4:12:25 PM UTC-4, rochacbruno wrote:
>>
>>
>> I am not sure if we can have classes in modules to define tables and them
>> pass DAL, response, request etc.. I need to test this approach.
>>
>
> That's how Auth and Crud work,
On Mon, May 2, 2011 at 6:48 PM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:
> from web2py import g
>
> g.request
> g.response
> g.db
> etc.
>
> without passing globals()
>
That will be really amazing thing!
by now I am developing using the new style model/subfolder definition and
for
Nice,but anthony is right when the application grow, you have the situation
that describe anthony.
2011/5/2 Anthony
> On Monday, May 2, 2011 10:33:59 AM UTC-4, pbreit wrote:
>>
>> Right, but I get no benefit then.
>
>
> If you've got models that are needed by multiple controllers, then there's
>
do you mean: db._common_fields.append(auth.signature)
i have it, and can test now
On Saturday, December 22, 2012 12:44:06 PM UTC-5, Massimo Di Pierro wrote:
>
> If you have fields with auth.signature and mysql/pgsql could you help me
> test the latest trunk?
>
> The reason is that I changed the
Yes. That would be a good test.
On Saturday, 22 December 2012 12:30:25 UTC-6, Adi wrote:
>
> do you mean: db._common_fields.append(auth.signature)
>
> i have it, and can test now
>
> On Saturday, December 22, 2012 12:44:06 PM UTC-5, Massimo Di Pierro wrote:
>>
>> If you have fields with auth.signa
Specifically let me know:
- after upgrade, do you see a migration in sql.log?
- does everything seem to work or you get a ticket?
Masimo
On Saturday, 22 December 2012 12:30:25 UTC-6, Adi wrote:
>
> do you mean: db._common_fields.append(auth.signature)
>
> i have it, and can test now
>
> On Saturd
My app was in a fake migration mode, and when I enabled a migration it
wanted to re-ecreate two existing tables, one regular (pmt), the other
archive (customer_archive)... (sql.log bellow).
I renamed existing tables in order to proceed...
What I see is that archive table got created with is_
This is not exactly what I was hoping for but it shows a problem with trunk.
It migrates is_active form notnull=False to notnull=True and then tries to
copy the old data (which include Null values).
This will break the migration. It worked for you because the step was only
faked. The creation o
let me know when you change. i can test again...
On Saturday, December 22, 2012 2:40:19 PM UTC-5, Massimo Di Pierro wrote:
>
> This is not exactly what I was hoping for but it shows a problem with
> trunk.
>
> It migrates is_active form notnull=False to notnull=True and then tries to
> copy th
I reverted it so there should be no problem. This leave the original
problem. If people add an auth signature, they must manually change
is_active=None to is_active=True.
On Saturday, 22 December 2012 13:59:13 UTC-6, Adi wrote:
>
> let me know when you change. i can test again...
>
> On Saturd
What happens if you add the field, set it to True,then add the notnull
constraint?
--
The problem is that adding notnull constraint causes a migration (except on
sqlite).
Because the field exists already web2py creates a new tmp field, than tried
to move existing data over. But the data contains Null while the new field
is notnull=True therefore the migration will fail.
On Sat
That's not a justified reason.
If I have a table with a column that has zero nulls in it, it is perfectly
reasonable for me to expect to be able to add a not-null constraint after
the fact.
If web2py is dealing with this migration, it should at least attempt to do
it correctly.
It should only f
46 matches
Mail list logo
