[web2py] Re: sqlhtml changes for sqlform.factory, not nice, 2.15.4 versus 2.18.5

2021-10-11 Thread 'Awe' via web2py-users
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

2021-10-09 Thread 'Awe' via web2py-users
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

2021-09-30 Thread 'Awe' via web2py-users
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

2021-08-04 Thread 'Awe' via web2py-users
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

2018-10-04 Thread 'Awe' via web2py-users
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

2018-10-01 Thread 'Awe' via web2py-users
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

2018-05-11 Thread 'Awe' via web2py-users
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

2018-03-19 Thread 'Awe' via web2py-users
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

2018-03-12 Thread 'Awe' via web2py-users
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

2018-03-09 Thread 'Awe' via web2py-users
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

2018-03-08 Thread 'Awe' via web2py-users
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

2018-03-07 Thread 'Awe' via web2py-users
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

2018-03-07 Thread 'Awe' via web2py-users
 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

2018-03-07 Thread 'Awe' via web2py-users
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

2018-03-05 Thread 'Awe' via web2py-users
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

2018-03-04 Thread 'Awe' via web2py-users
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

2018-03-02 Thread 'Awe' via web2py-users
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

2018-03-01 Thread 'Awe' via web2py-users
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.