Many requests don't require Auth at all (i.e., public part of website). Yet 
generating the navbar still requires an Auth instance. Just for the navbar, 
though, there's no reason to define all the db tables. Likewise, even for 
parts of the site that require login, @auth.requires_login() does not need 
the db tables (unless allow_basic_login is True), as it simply checks for 
"auth" in the session. Only things like registration, login, profile, 
@auth.requires_membership, and @auth.requires_permission really need the db 
tables, and in many apps, only a small proportion of requests use those 
functions. So doing:

auth = Auth(db)

without:

auth.define_tables()

can still be useful for many requests. Not a big savings, but about 5ms 
without lazy tables and 1-2ms with lazy tables (much bigger savings with 
migrations).

Anthony

On Saturday, September 1, 2012 8:24:51 AM UTC-4, Massimo Di Pierro wrote:
>
> I agree. What I do not understand is why would anybody want to instantiate 
> the auth object if the auth_* tables are not there. 
>
>     auth = Auth(db)
>     ... 
>     auth.define_tables()
>
> in my mind are like:
>
>     begin creating authentication logic
>     ....
>     end creating authentication logic
>
> If they are conditional both should be conditional.
> in fact the default layout checks for the presence of auth, why should it 
> check for the presence of db.auth_user? Anyway,as I said, I may be missing 
> something.
>
> On Friday, 31 August 2012 19:03:47 UTC-5, Anthony wrote:
>>
>> On Friday, August 31, 2012 3:11:20 PM UTC-4, Massimo Di Pierro wrote:
>>>
>>> what is the point of  auth = Auth(db) in your code without having an 
>>> auth_user table? I must be missing something about what you are trying to 
>>> do.
>>
>>
>> First, just to have the auth navbar appear on every page, it shouldn't be 
>> necessary to have any table definitions -- the navbar is constructed on 
>> every request, but many requests will be for non-protected pages on the 
>> public part of the website where auth isn't needed at all. Second, even for 
>> requests that require login, the database generally isn't needed -- logged 
>> in status is assessed by checking for the auth object in the session. The 
>> database should only be needed for login, registration, checking 
>> permissions, etc., but not simply for checking logged in status. So, on 
>> most requests, you might save some cycles by skipping the table definitions 
>> (admittedly, this is less of a savings with lazy tables, but still 
>> something).
>>
>> Anthony
>>
>

-- 



Reply via email to