[web2py] Re: help testing auth.signature with mysql/pgsql
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 fail if the table already contains nulls in that column. Otherwise, it should work. Web2py tries to circumvent a migration issue, and trips-on-itself because of bad-design of order-of-operations. It should temporarily add a default-constraint to the temp-field, to allow the setting of the not-null constraint while the new column is empty, THEN set the not-null constraint, THEN copy the data, and THEN remove the default-constraint in case the developer did not explicitly ask for it also. This way, the legitimate-expectation could be fulfilled, and only the non-legitimate expectation fail (in case there are really already nulls in that column) -- --- 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/groups/opt_out.
[web2py] Re: help testing auth.signature with mysql/pgsql
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 is_active field from notnull=False to notnull=True. This should trigger a migration of your data. I want to make sure nothing breaks. Can you confirm this is ok? Massimo --
[web2py] Re: help testing auth.signature with mysql/pgsql
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.signature and mysql/pgsql could you help me test the latest trunk? The reason is that I changed the is_active field from notnull=False to notnull=True. This should trigger a migration of your data. I want to make sure nothing breaks. Can you confirm this is ok? Massimo --
[web2py] Re: help testing auth.signature with mysql/pgsql
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 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 is_active field from notnull=False to notnull=True. This should trigger a migration of your data. I want to make sure nothing breaks. Can you confirm this is ok? Massimo --
[web2py] Re: help testing auth.signature with mysql/pgsql
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_active notnull, and default T, while existing tables stayed as is... Tried updating record in customer table and all worked ok... sql.log: timestamp: 2012-12-22T13:57:59.269217 ALTER TABLE lookup ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE lookup SET is_active__tmp=is_active; faked! ALTER TABLE lookup DROP COLUMN is_active; faked! ALTER TABLE lookup ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE lookup SET is_active=is_active__tmp; faked! ALTER TABLE lookup DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.298807 ALTER TABLE comment ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE comment SET is_active__tmp=is_active; faked! ALTER TABLE comment DROP COLUMN is_active; faked! ALTER TABLE comment ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE comment SET is_active=is_active__tmp; faked! ALTER TABLE comment DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.342240 ALTER TABLE configuration ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE configuration SET is_active__tmp=is_active; faked! ALTER TABLE configuration DROP COLUMN is_active; faked! ALTER TABLE configuration ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE configuration SET is_active=is_active__tmp; faked! ALTER TABLE configuration DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.375178 ALTER TABLE supplier ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE supplier SET is_active__tmp=is_active; faked! ALTER TABLE supplier DROP COLUMN is_active; faked! ALTER TABLE supplier ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE supplier SET is_active=is_active__tmp; faked! ALTER TABLE supplier DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.415936 ALTER TABLE customer ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE customer SET is_active__tmp=is_active; faked! ALTER TABLE customer DROP COLUMN is_active; faked! ALTER TABLE customer ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE customer SET is_active=is_active__tmp; faked! ALTER TABLE customer DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.464933 ALTER TABLE next_po_number ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE next_po_number SET is_active__tmp=is_active; faked! ALTER TABLE next_po_number DROP COLUMN is_active; faked! ALTER TABLE next_po_number ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE next_po_number SET is_active=is_active__tmp; faked! ALTER TABLE next_po_number DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.511872 ALTER TABLE purchase_order ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE purchase_order SET is_active__tmp=is_active; faked! ALTER TABLE purchase_order DROP COLUMN is_active; faked! ALTER TABLE purchase_order ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE purchase_order SET is_active=is_active__tmp; faked! ALTER TABLE purchase_order DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.618962 ALTER TABLE product_family ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE product_family SET is_active__tmp=is_active; faked! ALTER TABLE product_family DROP COLUMN is_active; faked! ALTER TABLE product_family ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE product_family SET is_active=is_active__tmp; faked! ALTER TABLE product_family DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.650635 ALTER TABLE sku ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE sku SET is_active__tmp=is_active; faked! ALTER TABLE sku DROP COLUMN is_active; faked! ALTER TABLE sku ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE sku SET is_active=is_active__tmp; faked! ALTER TABLE sku DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.688207 ALTER TABLE item ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE item SET is_active__tmp=is_active; faked! ALTER TABLE item DROP COLUMN is_active; faked! ALTER TABLE item ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE item SET is_active=is_active__tmp; faked! ALTER TABLE item DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T14:05:28.630734 CREATE TABLE pmt( id INT AUTO_INCREMENT NOT NULL, tbl_uuid VARCHAR(64), po_id INT, INDEX po_id__idx (po_id), FOREIGN KEY (po_id) REFERENCES purchase_order (id) ON DELETE CASCADE, currency VARCHAR(255), invoice_no VARCHAR(255), amount_paid DOUBLE, date_wire_actg DATE, partial_payment VARCHAR(255), amount_paid2 DOUBLE, date_to_actg2 DATE, amount_paid3 DOUBLE, date_to_actg3 DATE, amount_paid4
[web2py] Re: help testing auth.signature with mysql/pgsql
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 of the new table is never a problem. I have reverted the change in trunk. Massimo On Saturday, 22 December 2012 13:28:13 UTC-6, Adi wrote: 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_active notnull, and default T, while existing tables stayed as is... Tried updating record in customer table and all worked ok... sql.log: timestamp: 2012-12-22T13:57:59.269217 ALTER TABLE lookup ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE lookup SET is_active__tmp=is_active; faked! ALTER TABLE lookup DROP COLUMN is_active; faked! ALTER TABLE lookup ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE lookup SET is_active=is_active__tmp; faked! ALTER TABLE lookup DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.298807 ALTER TABLE comment ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE comment SET is_active__tmp=is_active; faked! ALTER TABLE comment DROP COLUMN is_active; faked! ALTER TABLE comment ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE comment SET is_active=is_active__tmp; faked! ALTER TABLE comment DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.342240 ALTER TABLE configuration ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE configuration SET is_active__tmp=is_active; faked! ALTER TABLE configuration DROP COLUMN is_active; faked! ALTER TABLE configuration ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE configuration SET is_active=is_active__tmp; faked! ALTER TABLE configuration DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.375178 ALTER TABLE supplier ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE supplier SET is_active__tmp=is_active; faked! ALTER TABLE supplier DROP COLUMN is_active; faked! ALTER TABLE supplier ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE supplier SET is_active=is_active__tmp; faked! ALTER TABLE supplier DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.415936 ALTER TABLE customer ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE customer SET is_active__tmp=is_active; faked! ALTER TABLE customer DROP COLUMN is_active; faked! ALTER TABLE customer ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE customer SET is_active=is_active__tmp; faked! ALTER TABLE customer DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.464933 ALTER TABLE next_po_number ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE next_po_number SET is_active__tmp=is_active; faked! ALTER TABLE next_po_number DROP COLUMN is_active; faked! ALTER TABLE next_po_number ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE next_po_number SET is_active=is_active__tmp; faked! ALTER TABLE next_po_number DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.511872 ALTER TABLE purchase_order ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE purchase_order SET is_active__tmp=is_active; faked! ALTER TABLE purchase_order DROP COLUMN is_active; faked! ALTER TABLE purchase_order ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE purchase_order SET is_active=is_active__tmp; faked! ALTER TABLE purchase_order DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.618962 ALTER TABLE product_family ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE product_family SET is_active__tmp=is_active; faked! ALTER TABLE product_family DROP COLUMN is_active; faked! ALTER TABLE product_family ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE product_family SET is_active=is_active__tmp; faked! ALTER TABLE product_family DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.650635 ALTER TABLE sku ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE sku SET is_active__tmp=is_active; faked! ALTER TABLE sku DROP COLUMN is_active; faked! ALTER TABLE sku ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE sku SET is_active=is_active__tmp; faked! ALTER TABLE sku DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.688207 ALTER TABLE item ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE item SET is_active__tmp=is_active; faked! ALTER TABLE item DROP COLUMN is_active; faked! ALTER TABLE item ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE item
[web2py] Re: help testing auth.signature with mysql/pgsql
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 the old data (which include Null values). This will break the migration. It worked for you because the step was only faked. The creation of the new table is never a problem. I have reverted the change in trunk. Massimo On Saturday, 22 December 2012 13:28:13 UTC-6, Adi wrote: 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_active notnull, and default T, while existing tables stayed as is... Tried updating record in customer table and all worked ok... sql.log: timestamp: 2012-12-22T13:57:59.269217 ALTER TABLE lookup ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE lookup SET is_active__tmp=is_active; faked! ALTER TABLE lookup DROP COLUMN is_active; faked! ALTER TABLE lookup ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE lookup SET is_active=is_active__tmp; faked! ALTER TABLE lookup DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.298807 ALTER TABLE comment ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE comment SET is_active__tmp=is_active; faked! ALTER TABLE comment DROP COLUMN is_active; faked! ALTER TABLE comment ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE comment SET is_active=is_active__tmp; faked! ALTER TABLE comment DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.342240 ALTER TABLE configuration ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE configuration SET is_active__tmp=is_active; faked! ALTER TABLE configuration DROP COLUMN is_active; faked! ALTER TABLE configuration ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE configuration SET is_active=is_active__tmp; faked! ALTER TABLE configuration DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.375178 ALTER TABLE supplier ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE supplier SET is_active__tmp=is_active; faked! ALTER TABLE supplier DROP COLUMN is_active; faked! ALTER TABLE supplier ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE supplier SET is_active=is_active__tmp; faked! ALTER TABLE supplier DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.415936 ALTER TABLE customer ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE customer SET is_active__tmp=is_active; faked! ALTER TABLE customer DROP COLUMN is_active; faked! ALTER TABLE customer ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE customer SET is_active=is_active__tmp; faked! ALTER TABLE customer DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.464933 ALTER TABLE next_po_number ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE next_po_number SET is_active__tmp=is_active; faked! ALTER TABLE next_po_number DROP COLUMN is_active; faked! ALTER TABLE next_po_number ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE next_po_number SET is_active=is_active__tmp; faked! ALTER TABLE next_po_number DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.511872 ALTER TABLE purchase_order ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE purchase_order SET is_active__tmp=is_active; faked! ALTER TABLE purchase_order DROP COLUMN is_active; faked! ALTER TABLE purchase_order ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE purchase_order SET is_active=is_active__tmp; faked! ALTER TABLE purchase_order DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.618962 ALTER TABLE product_family ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE product_family SET is_active__tmp=is_active; faked! ALTER TABLE product_family DROP COLUMN is_active; faked! ALTER TABLE product_family ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE product_family SET is_active=is_active__tmp; faked! ALTER TABLE product_family DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.650635 ALTER TABLE sku ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE sku SET is_active__tmp=is_active; faked! ALTER TABLE sku DROP COLUMN is_active; faked! ALTER TABLE sku ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE sku SET is_active=is_active__tmp; faked! ALTER TABLE sku DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.688207 ALTER TABLE item ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE item SET is_active__tmp=is_active;
[web2py] Re: help testing auth.signature with mysql/pgsql
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 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 the old data (which include Null values). This will break the migration. It worked for you because the step was only faked. The creation of the new table is never a problem. I have reverted the change in trunk. Massimo On Saturday, 22 December 2012 13:28:13 UTC-6, Adi wrote: 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_active notnull, and default T, while existing tables stayed as is... Tried updating record in customer table and all worked ok... sql.log: timestamp: 2012-12-22T13:57:59.269217 ALTER TABLE lookup ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE lookup SET is_active__tmp=is_active; faked! ALTER TABLE lookup DROP COLUMN is_active; faked! ALTER TABLE lookup ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE lookup SET is_active=is_active__tmp; faked! ALTER TABLE lookup DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.298807 ALTER TABLE comment ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE comment SET is_active__tmp=is_active; faked! ALTER TABLE comment DROP COLUMN is_active; faked! ALTER TABLE comment ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE comment SET is_active=is_active__tmp; faked! ALTER TABLE comment DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.342240 ALTER TABLE configuration ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE configuration SET is_active__tmp=is_active; faked! ALTER TABLE configuration DROP COLUMN is_active; faked! ALTER TABLE configuration ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE configuration SET is_active=is_active__tmp; faked! ALTER TABLE configuration DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.375178 ALTER TABLE supplier ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE supplier SET is_active__tmp=is_active; faked! ALTER TABLE supplier DROP COLUMN is_active; faked! ALTER TABLE supplier ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE supplier SET is_active=is_active__tmp; faked! ALTER TABLE supplier DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.415936 ALTER TABLE customer ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE customer SET is_active__tmp=is_active; faked! ALTER TABLE customer DROP COLUMN is_active; faked! ALTER TABLE customer ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE customer SET is_active=is_active__tmp; faked! ALTER TABLE customer DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.464933 ALTER TABLE next_po_number ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE next_po_number SET is_active__tmp=is_active; faked! ALTER TABLE next_po_number DROP COLUMN is_active; faked! ALTER TABLE next_po_number ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE next_po_number SET is_active=is_active__tmp; faked! ALTER TABLE next_po_number DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.511872 ALTER TABLE purchase_order ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE purchase_order SET is_active__tmp=is_active; faked! ALTER TABLE purchase_order DROP COLUMN is_active; faked! ALTER TABLE purchase_order ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE purchase_order SET is_active=is_active__tmp; faked! ALTER TABLE purchase_order DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.618962 ALTER TABLE product_family ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE product_family SET is_active__tmp=is_active; faked! ALTER TABLE product_family DROP COLUMN is_active; faked! ALTER TABLE product_family ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE product_family SET is_active=is_active__tmp; faked! ALTER TABLE product_family DROP COLUMN is_active__tmp; faked! timestamp: 2012-12-22T13:57:59.650635 ALTER TABLE sku ADD is_active__tmp CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE sku SET is_active__tmp=is_active; faked! ALTER TABLE sku DROP COLUMN is_active; faked! ALTER TABLE sku ADD is_active CHAR(1) NOT NULL DEFAULT 'T'; faked! UPDATE sku SET
[web2py] Re: help testing auth.signature with mysql/pgsql
What happens if you add the field, set it to True,then add the notnull constraint? --
[web2py] Re: help testing auth.signature with mysql/pgsql
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 Saturday, 22 December 2012 21:12:54 UTC-6, Cliff Kachinske wrote: What happens if you add the field, set it to True,then add the notnull constraint? --
Re: [web2py] Re: help testing
On Mon, May 2, 2011 at 2:38 AM, pbreit pbreitenb...@gmail.com 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 is, if you have a component with a specific need for a model, put that on specific folder.
[web2py] Re: help testing
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 May 1, 10:40 pm, Bruno Rocha rochacbr...@gmail.com wrote: 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 breaks compatibility unless there are people using subfolders for order execution arrangement. (which is not a documented feature, and not a recommended practice) Developers will need to think twice when modeling applications for choosing what to put in specific folder or not, but this matters only for bigger or componentized apps, small apps and prototypes or legacy apps would have just to work on the old way (all models on root folder). In the future, a routed approach will be a better way to define which model needs to be executed for each controller request. The automatic update will not breaks because it does not update user applications.
[web2py] Re: help testing
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 pbreitenb...@gmail.com wrote: This screams import to me. === default.py === from myapp.models import db def index() ...
[web2py] Re: help testing
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, controllers, modules, views, static, etc). What if we allowed plugins to be better organized?. If I have a plugin called plugin_test, I would have a 'test' folder under the plugins folder, and in that folder I would have models, controllers, and views folders. This way, plugins can be a bit more 'pluggable' and self-contained instead of them merging with everything else. Would this be a good idea?
[web2py] Re: help testing
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 cannot be a layout or a collection of static files etc. Nothing prevents us from creating a folder called plugins(*), move stuff under there and add logic so that when use calls an an action web2py looks in the usual place and also under the plugins folder but: these other types of plugins (once called y-plugins) would be a subset of the current plugin system; the extra logic would considerably slow down web2py because because of the increased file system and would considerably increase the complexity of the underlying code. Other than aesthetic considerations, I do not seen any technical advantage of y-plugins over current plugins. I only see disadvantages. Mind that you can already create y-plugins for modules (which may contain table definition), views (by using response.view to handle them) and static files (by using a custom action to serve them) and they would work with current plugin packaging mechanism. In the past I have challenged users to create a working proof of concept to show that they are worth it. Nobody ever did. Massimo On May 2, 8:53 am, Ross Peoples ross.peop...@gmail.com wrote: 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, controllers, modules, views, static, etc). What if we allowed plugins to be better organized?. If I have a plugin called plugin_test, I would have a 'test' folder under the plugins folder, and in that folder I would have models, controllers, and views folders. This way, plugins can be a bit more 'pluggable' and self-contained instead of them merging with everything else. Would this be a good idea?
Re: [web2py] Re: help testing
Right, but I get no benefit then.
[web2py] Re: help testing
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.
Re: [web2py] Re: help testing
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 models that are only needed for specific controllers or functions -- in that case, you run only the models you need for the specific request, and that can save some time/memory. If you need a particular model only for a few functions, but those functions are scattered across multiple controllers, then yes, this new change will not help -- for that, we'd need a more sophisticated router functionality. I take it, though, that the router approach would likely involve more effort to design and implement, so what we've got now is a quick change that will provide nice benefits for a lot of use cases, even if it's not yet as flexible as a full router based approach. Anthony
Re: [web2py] Re: help testing
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 have to be run on every request anyway. The benefit comes if you've got some models that are only needed for specific controllers or functions -- in that case, you run only the models you need for the specific request, and that can save some time/memory. If you need a particular model only for a few functions, but those functions are scattered across multiple controllers, then yes, this new change will not help -- for that, we'd need a more sophisticated router functionality. I take it, though, that the router approach would likely involve more effort to design and implement, so what we've got now is a quick change that will provide nice benefits for a lot of use cases, even if it's not yet as flexible as a full router based approach. Anthony
Re: [web2py] Re: help testing
Is routing the only other solution or would an import or import-like approach be feasible?
Re: [web2py] Re: help testing
On Mon, May 2, 2011 at 2:14 PM, pbreit pbreitenb...@gmail.com 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')
return dict()
Re: [web2py] Re: help testing
2011/5/2 Bruno Rocha rochacbr...@gmail.com:
On Mon, May 2, 2011 at 2:14 PM, pbreit pbreitenb...@gmail.com 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')
return dict()
what would be the difference from using import module?
Re: [web2py] Re: help testing
On Mon, May 2, 2011 at 4:57 PM, danto web2py.n...@gmail.com 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 implicit access, so you need to pass response, request, session, etc. if you want them to know your environment. models are executed and all objects defined there go to the memory in current environment context, modules need to be explicit imported, called and reloaded. 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. -- Bruno Rocha [ About me: http://zerp.ly/rochacbruno ]
Re: [web2py] Re: help testing
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?
Re: [web2py] Re: help testing
On Mon, May 2, 2011 at 5:22 PM, Anthony abasta...@gmail.com 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, no? You are right, but in this case we need to pass globals() and 'db' objects, how could the performance effect if for every module we pass globals() and db ? and we need to take care of reloading.
[web2py] Re: help testing
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 rochacbr...@gmail.com wrote: On Mon, May 2, 2011 at 5:22 PM, Anthony abasta...@gmail.com 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, no? You are right, but in this case we need to pass globals() and 'db' objects, how could the performance effect if for every module we pass globals() and db ? and we need to take care of reloading.
Re: [web2py] Re: help testing
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 web2py_components it is really nice! can I rely on this?
Re: [web2py] Re: help testing
Nice,but anthony is right when the application grow, you have the situation that describe anthony. 2011/5/2 Anthony abasta...@gmail.com 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 models that are only needed for specific controllers or functions -- in that case, you run only the models you need for the specific request, and that can save some time/memory. If you need a particular model only for a few functions, but those functions are scattered across multiple controllers, then yes, this new change will not help -- for that, we'd need a more sophisticated router functionality. I take it, though, that the router approach would likely involve more effort to design and implement, so what we've got now is a quick change that will provide nice benefits for a lot of use cases, even if it's not yet as flexible as a full router based approach. Anthony -- http://martin.tecnodoc.com.ar
[web2py] Re: help testing
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 mulone.mar...@gmail.com wrote: Nice,but anthony is right when the application grow, you have the situation that describe anthony. 2011/5/2 Anthony abasta...@gmail.com 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 models that are only needed for specific controllers or functions -- in that case, you run only the models you need for the specific request, and that can save some time/memory. If you need a particular model only for a few functions, but those functions are scattered across multiple controllers, then yes, this new change will not help -- for that, we'd need a more sophisticated router functionality. I take it, though, that the router approach would likely involve more effort to design and implement, so what we've got now is a quick change that will provide nice benefits for a lot of use cases, even if it's not yet as flexible as a full router based approach. Anthony -- http://martin.tecnodoc.com.ar
[web2py] Re: help testing
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 and because it is better to define code to be executed on demand in modules (not models), import them and call functions that do what you need conditionally. On May 1, 7:04 pm, Bruno Rocha rochacbr...@gmail.com wrote: great improvement, I am testing right now. A question that will raise soon is: How do I execute a model on demand? if I am in /default/foo and want an object defined in /default/bar, how do I force this model file to run? -- Bruno Rocha [ About me:http://zerp.ly/rochacbruno] On Sun, May 1, 2011 at 7:30 PM, Massimo Di Pierro massimo.dipie...@gmail.com wrote: In trunk we have - experimentally - conditional web2py models 1) models/anything.py (for all controllers) 2) models/c/anything.py (only forfunction in controller c) 3) models/c/f/anything.py (only for function f in controller c) when you canhttp:///c/f all models 1 are executed alphabetically, the 2 alphabetically then 3 alphabetically. Please help us test that: 1) it works 2) it works if you bytecode compile the app 3) it does not apps that were bytecode compiled with a previous web2py version This should provide a major speedup for those apps with lots of tables like ShanaEden. Massimo
Re: [web2py] Re: help testing
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 massimo.dipie...@gmail.com wrote: 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 and because it is better to define code to be executed on demand in modules (not models), import them and call functions that do what you need conditionally. On May 1, 7:04 pm, Bruno Rocha rochacbr...@gmail.com wrote: great improvement, I am testing right now. A question that will raise soon is: How do I execute a model on demand? if I am in /default/foo and want an object defined in /default/bar, how do I force this model file to run? -- Bruno Rocha [ About me:http://zerp.ly/rochacbruno] On Sun, May 1, 2011 at 7:30 PM, Massimo Di Pierro massimo.dipie...@gmail.com wrote: In trunk we have - experimentally - conditional web2py models 1) models/anything.py (for all controllers) 2) models/c/anything.py (only forfunction in controller c) 3) models/c/f/anything.py (only for function f in controller c) when you canhttp:///c/f all models 1 are executed alphabetically, the 2 alphabetically then 3 alphabetically. Please help us test that: 1) it works 2) it works if you bytecode compile the app 3) it does not apps that were bytecode compiled with a previous web2py version This should provide a major speedup for those apps with lots of tables like ShanaEden. Massimo
Re: [web2py] Re: help testing
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. This future is now! I think code organization with memory usage improvement is better than simply subfolders with models that will be always executed, even if they are not needed. May be we can have some king of compatibility check run_in_model_compatibility = True at some place, but. One thing we can always have in mind: Changes in undocumented features or bug fixing cannot be considered break of compatibility this is just the wrong usage, we ran in to this same issue when URL was changed. The way web2py imports all the models to memory is bad to performance, the new style is very good and enough. I am testing it now and I think it will be very productive. How can we manage this kind of interest conflict? -- Bruno Rocha [ About me: http://zerp.ly/rochacbruno ]
[web2py] Re: help testing
How about we provide a script that fixes that automatically? models/a/b.py - models/a_b/py is anybody else using model subfolder? Massimo On May 1, 8:09 pm, Thadeus Burgess thadeus.burg...@gmail.com wrote: 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 massimo.dipie...@gmail.com wrote: 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 and because it is better to define code to be executed on demand in modules (not models), import them and call functions that do what you need conditionally. On May 1, 7:04 pm, Bruno Rocha rochacbr...@gmail.com wrote: great improvement, I am testing right now. A question that will raise soon is: How do I execute a model on demand? if I am in /default/foo and want an object defined in /default/bar, how do I force this model file to run? -- Bruno Rocha [ About me:http://zerp.ly/rochacbruno] On Sun, May 1, 2011 at 7:30 PM, Massimo Di Pierro massimo.dipie...@gmail.com wrote: In trunk we have - experimentally - conditional web2py models 1) models/anything.py (for all controllers) 2) models/c/anything.py (only forfunction in controller c) 3) models/c/f/anything.py (only for function f in controller c) when you canhttp:///c/f all models 1 are executed alphabetically, the 2 alphabetically then 3 alphabetically. Please help us test that: 1) it works 2) it works if you bytecode compile the app 3) it does not apps that were bytecode compiled with a previous web2py version This should provide a major speedup for those apps with lots of tables like ShanaEden. Massimo
Re: [web2py] Re: help testing
Am I understanding correctly that we could save memory by not loading all models on all page views? That seems like a reasonable objective.
[web2py] Re: help testing
yes. You would not be saving memory as much as you would be saving time. On May 1, 9:50 pm, pbreit pbreitenb...@gmail.com 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.
[web2py] Re: help testing
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.
Re: [web2py] Re: help testing
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 pbreitenb...@gmail.com 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.
Re: [web2py] Re: help testing
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 on the same fodler is only executes when http:///app/default/index is requested models/default/contact/something.py # this model and all on the same fodler is only executes when http:///app/default/contact is requested Imagine a bigger app with too many tables, too many validators etc. there are no need to always load models of 'contact' page. -- Bruno Rocha [ About me: http://zerp.ly/rochacbruno ] On Sun, May 1, 2011 at 11:50 PM, pbreit pbreitenb...@gmail.com 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.
Re: [web2py] Re: help testing
Will need more tests or already is scheduled to play for production? _ *Gilson Filho* *Web Developer http://gilsondev.com* 2011/5/2 Bruno Rocha rochacbr...@gmail.com 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 on the same fodler is only executes when http:///app/default/index is requested models/default/contact/something.py # this model and all on the same fodler is only executes when http:///app/default/contact is requested Imagine a bigger app with too many tables, too many validators etc. there are no need to always load models of 'contact' page. -- Bruno Rocha [ About me: http://zerp.ly/rochacbruno ] On Sun, May 1, 2011 at 11:50 PM, pbreit pbreitenb...@gmail.com 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.
Re: [web2py] Re: help testing
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 put specific code on to models/component folder.. -- Bruno Rocha [ About me: http://zerp.ly/rochacbruno ] On Mon, May 2, 2011 at 12:08 AM, Bruno Rocha rochacbr...@gmail.com wrote: 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 on the same fodler is only executes when http:///app/default/index is requested models/default/contact/something.py # this model and all on the same fodler is only executes when http:///app/default/contact is requested Imagine a bigger app with too many tables, too many validators etc. there are no need to always load models of 'contact' page. -- Bruno Rocha [ About me: http://zerp.ly/rochacbruno ] On Sun, May 1, 2011 at 11:50 PM, pbreit pbreitenb...@gmail.com 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.
Re: [web2py] Re: help testing
On Mon, May 2, 2011 at 12:04 AM, pbreit pbreitenb...@gmail.com 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 better approach, but this folder approach is just the start, i see no problem for having both ways in the future, the folder way is the default, the routed way can be optional.
[web2py] Re: help testing
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 compatibility issue but I would like to know if other people have been doing that. Massimo On May 1, 10:13 pm, Gilson Filho cont...@gilsondev.com wrote: Will need more tests or already is scheduled to play for production? _ *Gilson Filho* *Web Developerhttp://gilsondev.com* 2011/5/2 Bruno Rocha rochacbr...@gmail.com 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 whenhttp:///app/default/*is requested models/default/index/something.py # this model and all on the same fodler is only executes whenhttp:///app/default/indexis requested models/default/contact/something.py # this model and all on the same fodler is only executes whenhttp:///app/default/contactis requested Imagine a bigger app with too many tables, too many validators etc. there are no need to always load models of 'contact' page. -- Bruno Rocha [ About me:http://zerp.ly/rochacbruno] On Sun, May 1, 2011 at 11:50 PM, pbreit pbreitenb...@gmail.com 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.
Re: [web2py] Re: help testing
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://gilsondev.com* 2011/5/2 Massimo Di Pierro massimo.dipie...@gmail.com 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 compatibility issue but I would like to know if other people have been doing that. Massimo On May 1, 10:13 pm, Gilson Filho cont...@gilsondev.com wrote: Will need more tests or already is scheduled to play for production? _ *Gilson Filho* *Web Developerhttp://gilsondev.com* 2011/5/2 Bruno Rocha rochacbr...@gmail.com 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 whenhttp:///app/default/*is requested models/default/index/something.py # this model and all on the same fodler is only executes whenhttp:///app/default/indexis requested models/default/contact/something.py # this model and all on the same fodler is only executes whenhttp:///app/default/contactis requested Imagine a bigger app with too many tables, too many validators etc. there are no need to always load models of 'contact' page. -- Bruno Rocha [ About me:http://zerp.ly/rochacbruno] On Sun, May 1, 2011 at 11:50 PM, pbreit pbreitenb...@gmail.com 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.
Re: [web2py] Re: help testing
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 breaks compatibility unless there are people using subfolders for order execution arrangement. (which is not a documented feature, and not a recommended practice) Developers will need to think twice when modeling applications for choosing what to put in specific folder or not, but this matters only for bigger or componentized apps, small apps and prototypes or legacy apps would have just to work on the old way (all models on root folder). In the future, a routed approach will be a better way to define which model needs to be executed for each controller request. The automatic update will not breaks because it does not update user applications.
Re: [web2py] Re: help testing
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.
Re: [web2py] Re: help testing
This screams import to me. === default.py === from myapp.models import db def index() ...
