[development] Variables, lookups, and memory usage
Donald A. Lobo
lobo at yahoo.com
Thu Dec 15 19:46:17 UTC 2005
with civicrm we've gone back-n-forth with what model
to use for various settings. We store all settings in
the DB (makes it easier to configure/tweak/translate
However, we ended up going down the road of creating
different tables for each setting (quite a few of the
tables share the same code). Probably the big factor
was the minor variation each setting had which needed
to be accomodated rather than shoe-horned into one
generic table. a good example is:
most settings just need: name , is_active, is_reserved
a few like state/country also need additional
abbreviate, country_id (for state)
idd_prefix, ndd_prefix (dialing code prefixes for
country), iso_code etc
ultimately we decided to go with seperate tables. In
retrospect, i would probably combine the table for the
generic case (which we'll probably do in 1.4) which
match the need exactly and keep the specific ones in
--- Allie Micka <allie at pajunas.com> wrote:
> >> I think discussed adding "domains" to the
> variable table a while back
> >> on this list.
> > Yes,. It was actually the first test DEP that I
> wrote. You can
> > probably search the mailing list for it.
> I admit I didn't take the time to absorb it fully,
> but It seems that
> the cascading variable system is about values and
> overriding them
> (think vertical), where the lookup stuff is more
> about segmenting/
> grouping data (think horizontal)
> I could be convinced that they're the same thing,
> but right now I
> feel like they're different. Storing
> states/countries/etc in lookup
> makes it a completely separate function from
> variables. But I
> considered storing expensive module settings here,
> got into a grey
> area, and came here for advice.
> To clarify, my main goal is to store settings while
> reducing memory
> consumption by not loading values on every page
> load. I'm inclined
> to go with a component module for now as a proof of
> concept, but
> input on making my strategy more
> generic/core-friendly is welcome.
> Mostly, I need to finish up these dependent modules
> soon, and I'd
> rather move forward than discuss it ad nauseum.
> With this list's
> input, I hope to move forward in a more
> informed/holistic way.
> > I look forward to seeing you in february. I am
> seeing you in
> > febs ,right ?
> I'm sure gonna try!
> Allie Micka
> pajunas interactive, inc.
> scalable web hosting and open source strategies
More information about the development