[web2py] Re: sqlhtml changes for sqlform.factory, not nice, 2.15.4 versus 2.18.5
Hello Massimo, thanks for replying. Maybe I didn't quite understand. I assumed that when using the Sqlform.factory no "record" is transmitted. This means that the "create" branch is always used in 2.21, 2.18, 2.15.4, independent of "create" or "edit" forms. In my point of view, for sqlform.factory, there is no difference between create / edit. For my purposes, the "old" code fields = [f.name for f in table if (ignore_rw or f.writable or f.readable) and (readonly or not f.compute)] was correct, cause I want to show a readable Field in an edit form, even when its value is "" but changing to "f.readable and f.default", when f.default = "", will result in a no show. Am I wrong? code, 2.21, 2.18, if fields is None: if not readonly: if not record: # create form should only show writable fields fields = [f.name for f in table if (ignore_rw or f.writable or (f.readable and f.default)) and not f.compute] else: # update form should also show readable fields and computed fields (but in reaodnly mode) fields = [f.name for f in table if (ignore_rw or f.writable or f.readable)] else: # read only form should show all readable fields fields = [f.name for f in table if (ignore_rw or f.readable)] Massimo Di Pierro schrieb am Sonntag, 10. Oktober 2021 um 06:27:42 UTC+2: > Looking at latest version 2.21. The change you mention is only for create > forms, not edit forms. It basically say if a field is readable and not > writable and has not value, it should not be displayed. It seems the > correct behavior to me. Maybe in 1.18 the same logic was incorrectly > applied to edit fors as well? Do not remember. Please try the latest. > > > > On Saturday, 9 October 2021 at 14:14:17 UTC-7 Awe wrote: > >> Thanks for the answer >> I haven't tried the latest version and I hope this behavior doesn't >> change from version to version.. >> but. I thought / hoped a web2py developer could explain why this >> important/central feature was changed and how to deal with it best. >> Jim S schrieb am Samstag, 2. Oktober 2021 um 16:26:42 UTC+2: >> >>> Have you tried with the latest web2py? >>> >>> I'm assuming the behavior is the same as with 2.18.5. >>> >>> Have you been able to pinpoint a commit that would have changed this >>> behavior? >>> >>> -Jim >>> >>> On Thursday, September 30, 2021 at 4:04:28 AM UTC-5 Awe wrote: >>> Is anybody out there facing the same problem, wondering about getting no answers... Awe schrieb am Mittwoch, 4. August 2021 um 18:16:40 UTC+2: > we are using sqlform.factory a lot, but the way fields are > shown/behave was changed from > 2.15.4 > fields = [f.name for f in table if (ignore_rw or f.writable or > f.readable) > and (readonly or not f.compute)] > to > 2.18.5 > fields = [f.name for f in table if (ignore_rw or f.writable or > (f.readable and f.default)) and not f.compute] > > so in 2.15.4 it was no problem to have an edit form with fields like > readable=True, writable=False, default="" > this field having an empty string was shown disabled, great as > expected. > > in 2.18.5 > this field will not be shown anymore, we need to set default=" " like > this, which is > not very useful. > > Is this a bug or feature, or is there a NEW common way to have empty > readonly fields in an > edit form > > Many thanks for any help! > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/web2py/6bd50f48-d1a5-4140-9946-08a9579ce41an%40googlegroups.com.
[web2py] Re: sqlhtml changes for sqlform.factory, not nice, 2.15.4 versus 2.18.5
Thanks for the answer I haven't tried the latest version and I hope this behavior doesn't change from version to version.. but. I thought / hoped a web2py developer could explain why this important/central feature was changed and how to deal with it best. Jim S schrieb am Samstag, 2. Oktober 2021 um 16:26:42 UTC+2: > Have you tried with the latest web2py? > > I'm assuming the behavior is the same as with 2.18.5. > > Have you been able to pinpoint a commit that would have changed this > behavior? > > -Jim > > On Thursday, September 30, 2021 at 4:04:28 AM UTC-5 Awe wrote: > >> Is anybody out there facing the same problem, wondering about getting no >> answers... >> >> Awe schrieb am Mittwoch, 4. August 2021 um 18:16:40 UTC+2: >> >>> we are using sqlform.factory a lot, but the way fields are shown/behave >>> was changed from >>> 2.15.4 >>> fields = [f.name for f in table if (ignore_rw or f.writable or f.readable) >>> and (readonly or not f.compute)] >>> to >>> 2.18.5 >>> fields = [f.name for f in table if (ignore_rw or f.writable or >>> (f.readable and f.default)) and not f.compute] >>> >>> so in 2.15.4 it was no problem to have an edit form with fields like >>> readable=True, writable=False, default="" >>> this field having an empty string was shown disabled, great as expected. >>> >>> in 2.18.5 >>> this field will not be shown anymore, we need to set default=" " like >>> this, which is >>> not very useful. >>> >>> Is this a bug or feature, or is there a NEW common way to have empty >>> readonly fields in an >>> edit form >>> >>> Many thanks for any help! >>> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/web2py/8f24f5bb-8608-4d72-8cca-a38dca5e6cc7n%40googlegroups.com.
[web2py] Re: sqlhtml changes for sqlform.factory, not nice, 2.15.4 versus 2.18.5
Is anybody out there facing the same problem, wondering about getting no answers... Awe schrieb am Mittwoch, 4. August 2021 um 18:16:40 UTC+2: > we are using sqlform.factory a lot, but the way fields are shown/behave > was changed from > 2.15.4 > fields = [f.name for f in table if (ignore_rw or f.writable or f.readable) > and (readonly or not f.compute)] > to > 2.18.5 > fields = [f.name for f in table if (ignore_rw or f.writable or > (f.readable and f.default)) and not f.compute] > > so in 2.15.4 it was no problem to have an edit form with fields like > readable=True, writable=False, default="" > this field having an empty string was shown disabled, great as expected. > > in 2.18.5 > this field will not be shown anymore, we need to set default=" " like > this, which is > not very useful. > > Is this a bug or feature, or is there a NEW common way to have empty > readonly fields in an > edit form > > Many thanks for any help! > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/web2py/37bfb538-aced-4313-a194-e8bbaa523a24n%40googlegroups.com.
[web2py] sqlhtml changes for sqlform.factory, not nice, 2.15.4 versus 2.18.5
we are using sqlform.factory a lot, but the way fields are shown/behave was changed from 2.15.4 fields = [f.name for f in table if (ignore_rw or f.writable or f.readable) and (readonly or not f.compute)] to 2.18.5 fields = [f.name for f in table if (ignore_rw or f.writable or (f.readable and f.default)) and not f.compute] so in 2.15.4 it was no problem to have an edit form with fields like readable=True, writable=False, default="" this field having an empty string was shown disabled, great as expected. in 2.18.5 this field will not be shown anymore, we need to set default=" " like this, which is not very useful. Is this a bug or feature, or is there a NEW common way to have empty readonly fields in an edit form Many thanks for any help! -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/web2py/07b2aae1-6fdb-419c-a129-6c9c833bab91n%40googlegroups.com.
[web2py] SQLFORM.factory in 2.17.1
in 2.16.1 this was fine: form = SQLFORM.factory( Field('always_show', default='123', readable=True, writable=False), Field('writable_if_intended', default='456', readable=True, writable=True), readonly=False, ) Both fields were shown, first field as textonly, and second one as edit/input field In 2.17.1 print form.fields ->['id', 'writable_if_intended'] The first field does not appear, so all my forms a broken for the moment and I do not know how to create a form with mixed intentions for the fields (readable only / and writable fields) many thanks for your help, Andreas -- 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.
[web2py] Re: web2py 2.17.1
Well, yes I think it breaks something, in 2.16.1 this was fine: form = SQLFORM.factory( Field('always_show', default='123', readable=True, writable=False), Field('writable_if_intended', default='456', readable=True, writable=True), readonly=False, ) Both fields were shown, first field as textonly, and second one as edit/input field In 2.17.1 print form.fields ->['id', 'writable_if_intended'] The first field does not appear, so all my forms a broken for the moment and I do not know how to create a form with mixed intentions for the fields (readable only / and writable fields) many thanks for your help, Andreas Am Montag, 13. August 2018 03:36:06 UTC+2 schrieb Massimo Di Pierro: > > On second look this is correct and intentional and fixed a bug. this form > is a from a factory and there is no record. the field is not writable > therefore it can only be displayed in read-only mode but there is no value > (record) to display. > > Does it break something? > > On Sunday, 12 August 2018 12:52:31 UTC-7, Jim Karsten wrote: >> >> I'm seeing a change in behaviour between versions 2.16.1 and 2.17.1. >> >> form = SQLFORM.factory(Field('name', writable=False)) >> print form.fields >> >> # In 2.16.1 prints: ['id', 'name'] >> # In 2.17.1 prints: ['id'] >> >> Is this intentional? >> >> -- 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.
[web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
Hello Leonel, opened this Issue on Mar 14, still no one assigned? Regards, Andreas Am Freitag, 9. März 2018 16:55:12 UTC+1 schrieb Leonel Câmara: > > This is definitely a bug, the solution doesn't seem easy, The problem is > that it should not apply the common filters on the alias used on the left > join again as they are already applied on the left join ON query itself. > > Please file an issue here: > https://github.com/web2py/pydal/issues > -- 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.
[web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
OK, issue filed on: 2018-03-14 Andreas Am Montag, 12. März 2018 09:14:22 UTC+1 schrieb Awe: > > Hello Leonel, > thanks for analyzing. Will open issue today. > Andreas > > Am Freitag, 9. März 2018 16:55:12 UTC+1 schrieb Leonel Câmara: >> >> This is definitely a bug, the solution doesn't seem easy, The problem is >> that it should not apply the common filters on the alias used on the left >> join again as they are already applied on the left join ON query itself. >> >> Please file an issue here: >> https://github.com/web2py/pydal/issues >> > -- 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.
[web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
Hello Leonel, thanks for analyzing. Will open issue today. Andreas Am Freitag, 9. März 2018 16:55:12 UTC+1 schrieb Leonel Câmara: > > This is definitely a bug, the solution doesn't seem easy, The problem is > that it should not apply the common filters on the alias used on the left > join again as they are already applied on the left join ON query itself. > > Please file an issue here: > https://github.com/web2py/pydal/issues > -- 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.
[web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
Hello Anthony, Richard: Here is a link to download a demo app: https://c.gmx.net/@316857413586131071/y6xMeU53Ql2MtJz-wr0-CQ Just install it, on the main page click the link. I just did the input written in the very first post. Additionally I attached a screenshot showing my result. Many thanks to You. Andreas Am Donnerstag, 8. März 2018 16:55:06 UTC+1 schrieb Anthony: > > On Thursday, March 8, 2018 at 10:28:38 AM UTC-5, Leonel Câmara wrote: >> >> Record versioning uses a common filter. >> >> Common filters do not work if you do not provide a query which is what >> happens when you do: >> >> db().select(db.test.ALL) >> >> You need to do: >> >> db(db.test.id > 0).select(db.test.ALL) >> > > I believe the query in question is: > > query = (test2.type_marker=='object') | (test2.type_marker==None) & (test1 > .type_marker=='person') > rows = current.db(query).select(test1.title, test2.title, left=test2.on( > test1.id==test2.granny)) > > So, there is a query being passed to db(). > > Anthony > -- 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.
Re: [web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
You wrote: In [4]: query = (test2.type_marker=='object') | (test2.type_marker==None) & (test1.type_marker=='person') ...: In [5]: db().select(db.test.ALL) Out[5]: So in [5] you did not use the query definition, its db() AND the result is 3 Rows, it should be 2! Thats why I asked for the query you will use to get exactly this result: test1.titletest2.title PeterNone PaulLaptop I haven't seen any query in your output with this result. Andreas Am Mittwoch, 7. März 2018 20:08:05 UTC+1 schrieb Richard: > > That why I think you wrongly initialize you db in the first place while > onboarding the record versioning feature... > > Please try on your side to create new app drop the model and fixture I > include in one of my last email and start web2py shell and launch the > various commands of yours... > > You should get the same output number of record... > > If you don't it might happen that there was a bug in 2.15.4 web2py version > / pyDAL... > > Try new version... > > On Wed, Mar 7, 2018 at 2:05 PM, Richard Vézina <ml.richa...@gmail.com > > wrote: > >> In [4]: query = (test2.type_marker=='object') | (test2.type_marker==None) >> & (test1.type_marker=='person') >>...: >> >> In [5]: db().select(db.test.ALL) >> Out[5]: >> >> I did there... >> >> Same result... >> >> That my point... >> >> On Wed, Mar 7, 2018 at 1:47 PM, 'Awe' via web2py-users < >> web...@googlegroups.com > wrote: >> >>> Hello Richard, >>> you are right, the use case is parent child relation. >>> All I want to point out is if you use this query: >>> "query = (test2.type_marker=='object') | (test2.type_marker==None) & >>> (test1.type_marker=='person')" >>> you do not get the same result with record versioning enabled or >>> disabled. >>> >>> Why do I use this query definition because I want to retrieve exactly >>> this result: >>> test1.titletest2.title >>> PeterNone >>> PaulLaptop >>> >>> If you use this query instead: >>> (test2.type_marker=='object') & (test1.type_marker=='person') >>> you do not get the result I need. >>> >>> The " | (test2.type_marker==None) " is necessary, due to parent/child >>> relationship. >>> >>> Please try exactly the query mentioned using versioning enabled/disabled >>> and see what happens. >>> >>> Many thanks for your patience. >>> >>> Am Mittwoch, 7. März 2018 19:34:41 UTC+1 schrieb Richard: >>>> >>>> I don't get it, I don't understand what is the issue... >>>> >>>> I just demonstrate that with and without record versioning DAL returns >>>> the same set of result which what it should be doing no?? >>>> >>>> So my understanding of the issue is that you don't get the same query >>>> output when record versioning is on and when it off which to me should is >>>> the issue you point us... I migth not understand the exact problem you >>>> have. >>>> >>>> But to me this "query = (test2.type_marker=='object') | >>>> (test2.type_marker==None) & (test1.type_marker=='person')" >>>> >>>> or this "query = (test2.type_marker=='object') & >>>> (test1.type_marker=='person')" with the set of inputs you have will lead >>>> to >>>> the same output as there is not type_marker NULL value... >>>> >>>> But I guess I miss something with related to what you try to achieve >>>> with this aliasing thing that you do... >>>> >>>> Also the use case is not obvious for me as why are you doing these >>>> aliases... I guess to retrieve some sort of genealogy/record parent-child >>>> relation... >>>> >>>> Richard >>>> >>>> >>>> On Wed, Mar 7, 2018 at 12:17 PM, 'Awe' via web2py-users < >>>> web...@googlegroups.com> wrote: >>>> >>>>> Hello Richard, >>>>> have read your post 3 times, but I can't find the right query result. >>>>> Could you tell me where to find in your test the query which leads to: >>>>> test1.titletest2.title >>>>> PeterNone >>>>> PaulLaptop >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> >
Re: [web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
Hello Richard, you are right, the use case is parent child relation. All I want to point out is if you use this query: "query = (test2.type_marker=='object') | (test2.type_marker==None) & (test1.type_marker=='person')" you do not get the same result with record versioning enabled or disabled. Why do I use this query definition because I want to retrieve exactly this result: test1.titletest2.title PeterNone PaulLaptop If you use this query instead: (test2.type_marker=='object') & (test1.type_marker=='person') you do not get the result I need. The " | (test2.type_marker==None) " is necessary, due to parent/child relationship. Please try exactly the query mentioned using versioning enabled/disabled and see what happens. Many thanks for your patience. Am Mittwoch, 7. März 2018 19:34:41 UTC+1 schrieb Richard: > > I don't get it, I don't understand what is the issue... > > I just demonstrate that with and without record versioning DAL returns the > same set of result which what it should be doing no?? > > So my understanding of the issue is that you don't get the same query > output when record versioning is on and when it off which to me should is > the issue you point us... I migth not understand the exact problem you have. > > But to me this "query = (test2.type_marker=='object') | > (test2.type_marker==None) & (test1.type_marker=='person')" > > or this "query = (test2.type_marker=='object') & > (test1.type_marker=='person')" with the set of inputs you have will lead to > the same output as there is not type_marker NULL value... > > But I guess I miss something with related to what you try to achieve with > this aliasing thing that you do... > > Also the use case is not obvious for me as why are you doing these > aliases... I guess to retrieve some sort of genealogy/record parent-child > relation... > > Richard > > > On Wed, Mar 7, 2018 at 12:17 PM, 'Awe' via web2py-users < > web...@googlegroups.com > wrote: > >> Hello Richard, >> have read your post 3 times, but I can't find the right query result. >> Could you tell me where to find in your test the query which leads to: >> test1.titletest2.title >> PeterNone >> PaulLaptop >> >> Thank you. >> >> >> >> >> >> Am Mittwoch, 7. März 2018 17:33:33 UTC+1 schrieb Richard: >> >>> Here some tests : >>> >>> *WITH record versioning* >>> >>> In [1]: db(db.test.id < 0).select() >>> Out[1]: >>> >>> In [2]: db(db.test.id > 0).select() >>> Out[2]: >>> >>> In [3]: test1 = db.test.with_alias('test1') >>> >>> In [4]: test2 = db.test.with_alias('test2') >>> >>> In [5]: query = (test2.type_marker=='object') | >>> (test2.type_marker==None) & (test1.type_marker=='person') >>> >>> In [6]: db().select(current.db.test.ALL) >>> >>> --- >>> NameError Traceback (most recent call >>> last) >>> /web2py_master_trunk/web2py/applications/test_versioning_issue/models/menu.py >>> >>> in () >>> > 1 db().select(current.db.test.ALL) >>> >>> NameError: name 'current' is not defined >>> >>> In [7]: db().select(db.test.ALL) >>> Out[7]: >>> >>> In [8]: query = (test2.type_marker=='object') & >>> (test1.type_marker=='person') >>> >>> In [9]: db().select(db.test.ALL) >>> Out[9]: >>> >>> In [10]: db(query).select(test1.title, test2.title, left=test2.on( >>> test1.id==test2.granny)) >>> Out[10]: >>> >>> In [11]: db(query)._select(test1.title, test2.title, left=test2.on( >>> test1.id==test2.granny)) >>> Out[11]: 'SELECT "test1"."title", "test2"."title" FROM "test" AS "test1" >>> LEFT JOIN "test" AS "test2" ON (("test1"."id" = "test2"."granny") AND >>> (("test1"."is_active" = \'T\') AND ("test2"."is_active" = \'T\'))) WHERE >>> "test2"."type_marker" = \'object\') AND ("test1"."type_marker" = >>> \'person\')) AND (("test1"."is_active" = \'T\') AND ("test2"."is_active" = >>> \'T\'))) AND (("test1"."is_active" = \'T\') AND ("test2"."
Re: [web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
is_active='is_active' > ) > > if db(db.test.id > 0).count() == 0: > db.test.insert(title='Peter', granny=None, type_marker='person') > db.test.insert(title='Paul', granny=None, type_marker='person') > db.test.insert(title='Laptop', granny=2, type_marker='object') > ``` > You can start the web2py shell like this : > > python web2py.py -a 'DUMMYPWD' -i 127.0.0.1 -p 8001 -S > test_versioning_issue -M > > > > I don't notice any discrepency between both result, I mean I recover 3 > records in both case... It makes sens that the raw query change to make > sure it select only active records... > > It mays happen that you experiment an issue with the web2py version that > you use 2.15.4... > > You may consider trying the above with a freshly create dummy app with the > db.py additions above and see by yourself... If you get the same results it > means that your own app may have been wrongly initialized in some way... If > yous till experiment the issue, try with the stable web2py version from the > web2py.com download page... > > Please report here your progress... > > If you determine that the issue is related to your old version of web2py, > please consider upgrade to the newer stable or wait for the next release > that Massimo's want to push soon. > > Thanks > > Richard > > On Wed, Mar 7, 2018 at 5:35 AM, 'Awe' via web2py-users < > web...@googlegroups.com > wrote: > >> Great, many thanks for testing it. >> Andreas >> >> Am Dienstag, 6. März 2018 22:30:59 UTC+1 schrieb Richard: >>> >>> Can you make a model definition with a fixture for loading the table, I >>> will make some test with trunk and various version to determine if it a >>> regression... Nevermind I just thought you provide that in the first >>> email... Let me have a look at that... >>> >>> Richard >>> >>> >>> >>> On Mon, Mar 5, 2018 at 2:02 PM, 'Awe' via web2py-users < >>> web...@googlegroups.com> wrote: >>> >>>> Hello Richard, >>>> it is not a problem of deleted or changed records. As shown in the >>>> example, there is the table and versioning defined. After that 3 records >>>> are inserted and then the query is executed. >>>> The defined query: >>>> query = (test2.type_marker=='object') | (test2.type_marker==None) & >>>> (test1.type_marker=='person') >>>> rows = current.db(query).select(test1.title, test2.title, >>>> left=test2.on(test1.id==test2.granny)) >>>> does not give the right result. >>>> I appreciate your help, maybe the problem gets easier to understand if >>>> you try to test the given example. >>>> Many thanks, >>>> Andreas >>>> >>>> >>>> Am Montag, 5. März 2018 16:05:26 UTC+1 schrieb Richard: >>>>> >>>>> Did you set the actual record that have been deleted to is_active = >>>>> False?? Or all the records that haven't be deleted yet to TRUE?? You have >>>>> to go in your backend and do an update there >>>>> >>>>> UPDATE stored_item >>>>> SET is_active = TRUE >>>>> WHERE is_active IS NULL >>>>> >>>>> If you didn't delete any record yet... >>>>> >>>>> You can also do it from web2py I guess with this command : >>>>> >>>>> db(db.stored_item.is_active == None).update(is_active=True) >>>>> db.commit() >>>>> >>>>> Then you both query should return the same thing... Or at least they >>>>> should... >>>>> >>>>> It important to initialize archive table and parent table properly >>>>> when you add audit trail table to an already existing table containing >>>>> record. >>>>> >>>>> I encourage you to read the book about record versioning : >>>>> http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#Record-versioning >>>>> >>>>> Richard >>>>> >>>>> On Sun, Mar 4, 2018 at 12:53 PM, 'Awe' via web2py-users < >>>>> web...@googlegroups.com> wrote: >>>>> >>>>>> Hello Richard, many thanks for analyzing. Everything you wrote is >>>>>> completely right. But I still do not understand the behaviour explained >>>>>> befor
Re: [web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
Great, many thanks for testing it. Andreas Am Dienstag, 6. März 2018 22:30:59 UTC+1 schrieb Richard: > > Can you make a model definition with a fixture for loading the table, I > will make some test with trunk and various version to determine if it a > regression... Nevermind I just thought you provide that in the first > email... Let me have a look at that... > > Richard > > > > On Mon, Mar 5, 2018 at 2:02 PM, 'Awe' via web2py-users < > web...@googlegroups.com > wrote: > >> Hello Richard, >> it is not a problem of deleted or changed records. As shown in the >> example, there is the table and versioning defined. After that 3 records >> are inserted and then the query is executed. >> The defined query: >> query = (test2.type_marker=='object') | (test2.type_marker==None) & >> (test1.type_marker=='person') >> rows = current.db(query).select(test1.title, test2.title, >> left=test2.on(test1.id==test2.granny)) >> does not give the right result. >> I appreciate your help, maybe the problem gets easier to understand if >> you try to test the given example. >> Many thanks, >> Andreas >> >> >> Am Montag, 5. März 2018 16:05:26 UTC+1 schrieb Richard: >>> >>> Did you set the actual record that have been deleted to is_active = >>> False?? Or all the records that haven't be deleted yet to TRUE?? You have >>> to go in your backend and do an update there >>> >>> UPDATE stored_item >>> SET is_active = TRUE >>> WHERE is_active IS NULL >>> >>> If you didn't delete any record yet... >>> >>> You can also do it from web2py I guess with this command : >>> >>> db(db.stored_item.is_active == None).update(is_active=True) >>> db.commit() >>> >>> Then you both query should return the same thing... Or at least they >>> should... >>> >>> It important to initialize archive table and parent table properly when >>> you add audit trail table to an already existing table containing record. >>> >>> I encourage you to read the book about record versioning : >>> http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#Record-versioning >>> >>> Richard >>> >>> On Sun, Mar 4, 2018 at 12:53 PM, 'Awe' via web2py-users < >>> web...@googlegroups.com> wrote: >>> >>>> Hello Richard, many thanks for analyzing. Everything you wrote is >>>> completely right. But I still do not understand the behaviour explained >>>> before. >>>> If you look at the table posted before, all is_acitve Flags are TRUE. >>>> to get the result I need, I have defined: >>>> query = (test2.type_marker=='object') | (test2.type_marker==None) & >>>> (test1.type_marker=='person') >>>> rows = current.db(query).select(test1.title, test2.title, >>>> left=test2.on(test1.id==test2.granny)) >>>> >>>> the raw sql of this query WITHOUT record versioning is fine. >>>> SELECT "test1"."title", "test2"."title" FROM "test" AS "test1" LEFT >>>> JOIN "test" AS "test2" ON ("test1"."id" = "test2"."granny") WHERE >>>> (("test2"."type_marker" = 'object') OR (("test2"."type_marker" IS NULL) >>>> AND >>>> ("test1"."type_marker" = 'person'))); >>>> And the result is the way it suposed to be: >>>> >>>> test1.titletest2.title >>>> PeterNone >>>> PaulLaptop >>>> >>>> The result with record versioning enabled is different: >>>> test1.titletest2.title >>>> PaulLaptop >>>> >>>> Even when the is_acitve Field is defined like that: >>>> >>>> Field('is_active', 'boolean', writable=False, readable=False, >>>> default=True,required=True, requires=IS_NOT_EMPTY()), >>>> >>>> So maybe I miss something? At the moment I still wonder why the identical >>>> query comes to different results. >>>> >>>> >>>> Best regards, an many thanks for your help! >>>> Andreas >>>> >>>> >>>> >>>> >>>> >>>> Am Freitag, 2. März 2018 16:59:35 UTC+1 schrieb Richard: >>>>> >>>>> Hmm
Re: [web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
Hello Richard, it is not a problem of deleted or changed records. As shown in the example, there is the table and versioning defined. After that 3 records are inserted and then the query is executed. The defined query: query = (test2.type_marker=='object') | (test2.type_marker==None) & (test1.type_marker=='person') rows = current.db(query).select(test1.title, test2.title, left=test2.on( test1.id==test2.granny)) does not give the right result. I appreciate your help, maybe the problem gets easier to understand if you try to test the given example. Many thanks, Andreas Am Montag, 5. März 2018 16:05:26 UTC+1 schrieb Richard: > > Did you set the actual record that have been deleted to is_active = > False?? Or all the records that haven't be deleted yet to TRUE?? You have > to go in your backend and do an update there > > UPDATE stored_item > SET is_active = TRUE > WHERE is_active IS NULL > > If you didn't delete any record yet... > > You can also do it from web2py I guess with this command : > > db(db.stored_item.is_active == None).update(is_active=True) > db.commit() > > Then you both query should return the same thing... Or at least they > should... > > It important to initialize archive table and parent table properly when > you add audit trail table to an already existing table containing record. > > I encourage you to read the book about record versioning : > http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#Record-versioning > > Richard > > On Sun, Mar 4, 2018 at 12:53 PM, 'Awe' via web2py-users < > web...@googlegroups.com > wrote: > >> Hello Richard, many thanks for analyzing. Everything you wrote is >> completely right. But I still do not understand the behaviour explained >> before. >> If you look at the table posted before, all is_acitve Flags are TRUE. >> to get the result I need, I have defined: >> query = (test2.type_marker=='object') | (test2.type_marker==None) & >> (test1.type_marker=='person') >> rows = current.db(query).select(test1.title, test2.title, >> left=test2.on(test1.id==test2.granny)) >> >> the raw sql of this query WITHOUT record versioning is fine. >> SELECT "test1"."title", "test2"."title" FROM "test" AS "test1" LEFT JOIN >> "test" AS "test2" ON ("test1"."id" = "test2"."granny") WHERE >> (("test2"."type_marker" = 'object') OR (("test2"."type_marker" IS NULL) AND >> ("test1"."type_marker" = 'person'))); >> And the result is the way it suposed to be: >> >> test1.titletest2.title >> PeterNone >> PaulLaptop >> >> The result with record versioning enabled is different: >> test1.titletest2.title >> PaulLaptop >> >> Even when the is_acitve Field is defined like that: >> >> Field('is_active', 'boolean', writable=False, readable=False, >> default=True,required=True, requires=IS_NOT_EMPTY()), >> >> So maybe I miss something? At the moment I still wonder why the identical >> query comes to different results. >> >> >> Best regards, an many thanks for your help! >> Andreas >> >> >> >> >> >> Am Freitag, 2. März 2018 16:59:35 UTC+1 schrieb Richard: >>> >>> Hmmm... I think that if you have record versioning activated there >>> shouldn't be any is_active row(s) with NULL value... I mean is_active flag >>> is used to determine if the record in the "parent" table has been deleted >>> or not, since you can truely deleted in case you use record versioning >>> feature as all the previous record stated records contained in the >>> versioning table reference the parent record in the parent table... >>> >>> And you see in the second example here : >>> >>> >>> http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer?search=record+versioning#Record-versioning >>> >>> That is_active is set to default=True and there is this note : >>> >>> Notice the hidden boolean field called is_active and defaulting to True. >>> >>> So if you have activated record versioning feature over an already >>> existing table you need to set is_active to TRUE for all the existing >>> record once you start using the versioning feature and set the is_active to >>> be mandatory... >>> >>> I guess it would make sens to change seconde
Re: [web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
Hello Richard, many thanks for analyzing. Everything you wrote is completely right. But I still do not understand the behaviour explained before. If you look at the table posted before, all is_acitve Flags are TRUE. to get the result I need, I have defined: query = (test2.type_marker=='object') | (test2.type_marker==None) & (test1.type_marker=='person') rows = current.db(query).select(test1.title, test2.title, left=test2.on( test1.id==test2.granny)) the raw sql of this query WITHOUT record versioning is fine. SELECT "test1"."title", "test2"."title" FROM "test" AS "test1" LEFT JOIN "test" AS "test2" ON ("test1"."id" = "test2"."granny") WHERE (("test2"."type_marker" = 'object') OR (("test2"."type_marker" IS NULL) AND ("test1"."type_marker" = 'person'))); And the result is the way it suposed to be: test1.titletest2.title PeterNone PaulLaptop The result with record versioning enabled is different: test1.titletest2.title PaulLaptop Even when the is_acitve Field is defined like that: Field('is_active', 'boolean', writable=False, readable=False, default=True,required=True, requires=IS_NOT_EMPTY()), So maybe I miss something? At the moment I still wonder why the identical query comes to different results. Best regards, an many thanks for your help! Andreas Am Freitag, 2. März 2018 16:59:35 UTC+1 schrieb Richard: > > Hmmm... I think that if you have record versioning activated there > shouldn't be any is_active row(s) with NULL value... I mean is_active flag > is used to determine if the record in the "parent" table has been deleted > or not, since you can truely deleted in case you use record versioning > feature as all the previous record stated records contained in the > versioning table reference the parent record in the parent table... > > And you see in the second example here : > > > http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer?search=record+versioning#Record-versioning > > That is_active is set to default=True and there is this note : > > Notice the hidden boolean field called is_active and defaulting to True. > > So if you have activated record versioning feature over an already > existing table you need to set is_active to TRUE for all the existing > record once you start using the versioning feature and set the is_active to > be mandatory... > > I guess it would make sens to change seconde book example in orther that > is should be more obvious that is_active is mandatory like so : > > db.define_table('stored_item', > Field('name'), > Field('quantity', 'integer'), > Field('is_active', 'boolean', > writable=False, readable=False, default=True, > required=True, requires=IS_NOT_EMPTY())) > > > > That way you don't need to care about null value to get all the records of > the parent table and DAL is not bugged... > > Richard > > On Fri, Mar 2, 2018 at 9:22 AM, 'Awe' via web2py-users < > web...@googlegroups.com > wrote: > >> So, I did check it again: >> >> It seems that DAL is not able to handle a left join using ISNULL >> condition in combination with enabled record versioning. >> There are two "is active" checks within the left join: OK >> The next two upcoming ANDs to check "is_active" are not necessary and >> actually prohibit the query to work properly. >> To make this work it should be: AND (("test1"."is_active" = 'T') AND >> (("test2"."is_active" = 'T' OR ("test2"."is_active" ISNULL )) >> The two AND is active checks at the end of the query are not necessary at >> all (my opinion). >> >> Could somebody please verifiy this! >> Andreas >> >> >> Am Donnerstag, 1. März 2018 13:37:59 UTC+1 schrieb Awe: >>> >>> Hello, >>> I post a simple step by step example, to explain. >>> Doing a left join and using a where clause like: table.field==None >>> Depending on _enable_record_versioning is enabled or not, I get >>> different results when executing the identical query. >>> The result when versioning is DISABLED is the correct one. >>> >>> 2.15.4-stable+timestamp.2017.09.02.04.02.22 >>> (läuft auf Rocket 1.2.6, Python 2.7.12) >>> SQLite DB >>> >>> Example: >>> >>> #simple table: >>> current.db.define_table('test', >>>Field('title', 'str
[web2py] Re: Unexpected behaviour executing a query with DAL and record versioning enabled
So, I did check it again: It seems that DAL is not able to handle a left join using ISNULL condition in combination with enabled record versioning. There are two "is active" checks within the left join: OK The next two upcoming ANDs to check "is_active" are not necessary and actually prohibit the query to work properly. To make this work it should be: AND (("test1"."is_active" = 'T') AND (("test2"."is_active" = 'T' OR ("test2"."is_active" ISNULL )) The two AND is active checks at the end of the query are not necessary at all (my opinion). Could somebody please verifiy this! Andreas Am Donnerstag, 1. März 2018 13:37:59 UTC+1 schrieb Awe: > > Hello, > I post a simple step by step example, to explain. > Doing a left join and using a where clause like: table.field==None > Depending on _enable_record_versioning is enabled or not, I get different > results when executing the identical query. > The result when versioning is DISABLED is the correct one. > > 2.15.4-stable+timestamp.2017.09.02.04.02.22 > (läuft auf Rocket 1.2.6, Python 2.7.12) > SQLite DB > > Example: > > #simple table: > current.db.define_table('test', >Field('title', 'string'), >Field('granny', 'reference test'), # convenience - > topmost >Field('type_marker', 'string'), >auth.signature, >) > #versioning, enable/disable it > current.db.test._enable_record_versioning(archive_db=current.db, > archive_name='test_archive', > current_record='current_record', > is_active='is_active' > ) > > #put some data in > #current.db.test.insert(**{'title': 'Peter', 'granny': None, > 'type_marker': 'person'}) > #current.db.test.insert(**{'title': 'Paul', 'granny': None, 'type_marker': > 'person'}) > #current.db.test.insert(**{'title': 'Laptop', 'granny': 2, 'type_marker': > 'object'}) > > #so you get table content (enabled)t: > test.idtest.titletest.grannytest.type_marker > test.is_activetest.created_ontest.created_by > test.modified_ontest.modified_by > 1 Peter Noneperson > True2018-03-01 08:11:40Me2018-03-01 > 08:11:40Me > 2 Paul Noneperson > True2018-03-01 08:11:40Me2018-03-01 > 08:11:40Me > 3 Laptop 2 object > True2018-03-01 08:11:40Me2018-03-01 > 08:11:40Me > > #simple controller function > def demo(): > test1=current.db.test.with_alias('test1') > test2=current.db.test.with_alias('test2') > query = (test2.type_marker=='object') | (test2.type_marker==None) & > (test1.type_marker=='person') > tbl = current.db().select(current.db.test.ALL) > rows = current.db(query).select(test1.title, test2.title, > left=test2.on(test1.id==test2.granny)) > prn = current.db(query)._select(test1.title, test2.title, > left=test2.on(test1.id==test2.granny)) > return dict(tbl=tbl, rows=rows, prn=prn) > > Result/Output: > test1.titletest2.title > PaulLaptop > > Raw SQL: > SELECT "test1"."title", "test2"."title" FROM "test" AS "test1" LEFT JOIN > "test" AS "test2" ON (("test1"."id" = "test2"."granny") AND > (("test1"."is_active" = 'T') AND ("test2"."is_active" = 'T'))) WHERE > "test2"."type_marker" = 'object') OR (("test2"."type_marker" IS NULL) > AND ("test1"."type_marker" = 'person'))) AND (("test1"."is_active" = 'T') > AND ("test2"."is_active" = 'T'))) AND (("test1"."is_active" = 'T') AND > ("test2"."is_active" = 'T'))); > > > NOW DISABLED Record versioning: > > Result/Output: > test1.titletest2.title > PeterNone > PaulLaptop > > Raw SQL: > SELECT "test1"."title", "test2"."title" FROM "test" AS "test1" LEFT JOIN > "test" AS "test2" ON ("test1"."id" = "test2"."granny") WHERE > (("test2"."type_marker" = 'object') OR (("test2"."type_marker" IS NULL) AND > ("test1"."type_marker" = 'person'))); > > QUESTION: > The result with versioning turned off looks right. > It seems that the automatically inserted "AND... is_active" clauses are > not correct. > Many thanks for your help and assistance. > Andreas > > -- 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.
[web2py] Unexpected behaviour executing a query with DAL and record versioning enabled
Hello, I post a simple step by step example, to explain. Doing a left join and using a where clause like: table.field==None Depending on _enable_record_versioning is enabled or not, I get different results when executing the identical query. The result when versioning is DISABLED is the correct one. 2.15.4-stable+timestamp.2017.09.02.04.02.22 (läuft auf Rocket 1.2.6, Python 2.7.12) SQLite DB Example: #simple table: current.db.define_table('test', Field('title', 'string'), Field('granny', 'reference test'), # convenience - topmost Field('type_marker', 'string'), auth.signature, ) #versioning, enable/disable it current.db.test._enable_record_versioning(archive_db=current.db, archive_name='test_archive', current_record='current_record', is_active='is_active' ) #put some data in #current.db.test.insert(**{'title': 'Peter', 'granny': None, 'type_marker': 'person'}) #current.db.test.insert(**{'title': 'Paul', 'granny': None, 'type_marker': 'person'}) #current.db.test.insert(**{'title': 'Laptop', 'granny': 2, 'type_marker': 'object'}) #so you get table content (enabled)t: test.idtest.titletest.grannytest.type_marker test.is_activetest.created_ontest.created_by test.modified_ontest.modified_by 1 Peter Noneperson True2018-03-01 08:11:40Me2018-03-01 08:11:40Me 2 Paul Noneperson True2018-03-01 08:11:40Me2018-03-01 08:11:40Me 3 Laptop 2 object True2018-03-01 08:11:40Me2018-03-01 08:11:40Me #simple controller function def demo(): test1=current.db.test.with_alias('test1') test2=current.db.test.with_alias('test2') query = (test2.type_marker=='object') | (test2.type_marker==None) & (test1.type_marker=='person') tbl = current.db().select(current.db.test.ALL) rows = current.db(query).select(test1.title, test2.title, left=test2.on(test1.id==test2.granny)) prn = current.db(query)._select(test1.title, test2.title, left=test2.on(test1.id==test2.granny)) return dict(tbl=tbl, rows=rows, prn=prn) Result/Output: test1.titletest2.title PaulLaptop Raw SQL: SELECT "test1"."title", "test2"."title" FROM "test" AS "test1" LEFT JOIN "test" AS "test2" ON (("test1"."id" = "test2"."granny") AND (("test1"."is_active" = 'T') AND ("test2"."is_active" = 'T'))) WHERE "test2"."type_marker" = 'object') OR (("test2"."type_marker" IS NULL) AND ("test1"."type_marker" = 'person'))) AND (("test1"."is_active" = 'T') AND ("test2"."is_active" = 'T'))) AND (("test1"."is_active" = 'T') AND ("test2"."is_active" = 'T'))); NOW DISABLED Record versioning: Result/Output: test1.titletest2.title PeterNone PaulLaptop Raw SQL: SELECT "test1"."title", "test2"."title" FROM "test" AS "test1" LEFT JOIN "test" AS "test2" ON ("test1"."id" = "test2"."granny") WHERE (("test2"."type_marker" = 'object') OR (("test2"."type_marker" IS NULL) AND ("test1"."type_marker" = 'person'))); QUESTION: The result with versioning turned off looks right. It seems that the automatically inserted "AND... is_active" clauses are not correct. Many thanks for your help and assistance. Andreas -- 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.