You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2001/09/20 19:21:39 UTC
perl{set|add}var logic
I've implemented (well almost) PerlSetVar/PerlAddVar/dir_config but I'm
a little bit confused of the correct spec. So please confirm.
PerlSetVar sets the key => val
that's easy.
PerlAddVar key val
pushes the value to the list. Now if I implement the whole storage with
apr_table_t, it's easy to do the settings, but a hell on retrieval, not
talking about speed as I have to go through the whole list to make sure
that some key doesn't have more than one value.
If I implement the storage as an apr_hash_t, the look up is much faster
and simpler (that's what we want, since we mostly do lookups at the run
time). But how do I maintain a list? Luckily apr_hash_t want a void type
for the value so I can pass it a list.
So what's the correct way to do it if we do it with apr_hash?
PerlSetVar to set a normal (char *key, char *val)
PerlAddVar first to do a lookup and
if the key is there already
if the value is a list, push to the end of the list
else retrieve the string, create a list and put it as a value
Now the retrieve procedure is as follows:
get the void val, look at it,
if it's a string return it, casting it in the right way)
else must be a list, return the list (casting it)
Alternatively we could always use a hash of lists and always add values
to the lists. Less logic, more space, slower on average (assuming that
it's rare that we have a more than one value for one key).
Which way should we take?
It'll be very nice if APR::Table could handle this automagically. Or
should we have a new apr class to handle hashes of lists?
---------
now the second part: dir_config
is that correct?
@values = $r->dir_config('key');
@values = $r->dir_config->{key};
%hash = $r->dir_config; # Hash of lists!
Thanks!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perl{set|add}var logic
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Fri, 21 Sep 2001, Stas Bekman wrote:
>
>
>>So on fetch
>>
>> @values = $r->dir_config('key');
>>
>>it's ok to iterate through the whole apr_table_t to make sure that all keys
>>
>>are fetched. I'm not sure how the tied interface APR::Table->FETCH accomodates
>>
>>this? I should look at the recent patches.
>>
>
> or look at what 1.x does.
I did. I just wasn't sure whether we keep it the same way.
>>So basically what you say is that using apr_table_t should be fine for the needs
>>
>>of Perl{Add|Set}Var, right?
>>
>
> yeah, we can always optmize later if needed. also, brian pane posted a
> patch to implement apr_table_t on top of apr_hash_t. the idea was
> rejected for apr/httpd, but we could always borrow the implementation for
> mod_perl.
Yup, I remember the discussion. As you say we can get it done later.
--
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perl{set|add}var logic
Posted by Doug MacEachern <do...@covalent.net>.
On Fri, 21 Sep 2001, Stas Bekman wrote:
> So on fetch
>
> @values = $r->dir_config('key');
>
> it's ok to iterate through the whole apr_table_t to make sure that all keys
>
> are fetched. I'm not sure how the tied interface APR::Table->FETCH accomodates
>
> this? I should look at the recent patches.
or look at what 1.x does.
> So basically what you say is that using apr_table_t should be fine for the needs
>
> of Perl{Add|Set}Var, right?
yeah, we can always optmize later if needed. also, brian pane posted a
patch to implement apr_table_t on top of apr_hash_t. the idea was
rejected for apr/httpd, but we could always borrow the implementation for
mod_perl.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perl{set|add}var logic
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Fri, 21 Sep 2001, Stas Bekman wrote:
>
>
>>If I implement the storage as an apr_hash_t, the look up is much faster
>>and simpler (that's what we want, since we mostly do lookups at the run
>>time). But how do I maintain a list? Luckily apr_hash_t want a void type
>>for the value so I can pass it a list.
>>
>
> you could do:
> typedef struct {
> int num;
> union {
> const char *val;
> apr_array_header_t *values;
> } val;
> } modperl_var_t;
>
> if (num > 1) use the values, else use the val. but that'll get messy.
> might be better off to always use an apr_array_header_t for the values.
>
>
>>Alternatively we could always use a hash of lists and always add values
>>to the lists. Less logic, more space, slower on average (assuming that
>>it's rare that we have a more than one value for one key).
>>
>
> shouldn't be too much slower. extra space should on be on the order of 20
> bytes, not too bad.
sounds good, but as you say below there is a lot of code to write to
support this.
>>It'll be very nice if APR::Table could handle this automagically. Or
>>should we have a new apr class to handle hashes of lists?
>>
>
> APR::Table is an apr_table_t, not an apr_hash_t.
> if Perl{Set,Add}Var is moved to an apr_hash_t, it will need its own api.
> i don't know if its even worth implementing Perl{Set,Add}Var as
> apr_hash_t, the table per-dir is never more than a few entries.
So on fetch
@values = $r->dir_config('key');
it's ok to iterate through the whole apr_table_t to make sure that all keys
are fetched. I'm not sure how the tied interface APR::Table->FETCH accomodates
this? I should look at the recent patches.
So basically what you say is that using apr_table_t should be fine for the needs
of Perl{Add|Set}Var, right?
>>---------
>>
>>now the second part: dir_config
>>
>>is that correct?
>>
>>@values = $r->dir_config('key');
>>@values = $r->dir_config->{key};
>>
>
> right.
>
>
>>%hash = $r->dir_config; # Hash of lists!
>>
>
> the 1.x api returns a $table object, 2.0 should do the same.
> which is also what you second example does:
> @values = $r->dir_config ->{key};
> ^^^^^^^^^^^^^^
> there's no way to treat that different from $r->dir_config; without
> examining the op tree, which i don't think we want to do.
that was my mistake, I meant:
$obj = $r->dir_config;
Thanks, Doug!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perl{set|add}var logic
Posted by Doug MacEachern <do...@covalent.net>.
On Fri, 21 Sep 2001, Stas Bekman wrote:
> If I implement the storage as an apr_hash_t, the look up is much faster
> and simpler (that's what we want, since we mostly do lookups at the run
> time). But how do I maintain a list? Luckily apr_hash_t want a void type
> for the value so I can pass it a list.
you could do:
typedef struct {
int num;
union {
const char *val;
apr_array_header_t *values;
} val;
} modperl_var_t;
if (num > 1) use the values, else use the val. but that'll get messy.
might be better off to always use an apr_array_header_t for the values.
> Alternatively we could always use a hash of lists and always add values
> to the lists. Less logic, more space, slower on average (assuming that
> it's rare that we have a more than one value for one key).
shouldn't be too much slower. extra space should on be on the order of 20
bytes, not too bad.
> It'll be very nice if APR::Table could handle this automagically. Or
> should we have a new apr class to handle hashes of lists?
APR::Table is an apr_table_t, not an apr_hash_t.
if Perl{Set,Add}Var is moved to an apr_hash_t, it will need its own api.
i don't know if its even worth implementing Perl{Set,Add}Var as
apr_hash_t, the table per-dir is never more than a few entries.
> ---------
>
> now the second part: dir_config
>
> is that correct?
>
> @values = $r->dir_config('key');
> @values = $r->dir_config->{key};
right.
> %hash = $r->dir_config; # Hash of lists!
the 1.x api returns a $table object, 2.0 should do the same.
which is also what you second example does:
@values = $r->dir_config ->{key};
^^^^^^^^^^^^^^
there's no way to treat that different from $r->dir_config; without
examining the op tree, which i don't think we want to do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org