- We've introduced a new database cache table (civicrm_cache) to cache a few database queries that are repeated a lot. Some of the specific queries include listing all the fields available for the contact types (individual/org/household). This is a combination of the built-in fields (name, address etc) and the custom fields added by the user. This reduces the number of queries invoked from 5 complex queries to 1 simple cache query (and an un-serialize)
- We've added a column (group_type) to the profile table (civicrm_uf_group), so we know the profile type rather than recompute it every time we need it.
- Thanx to Dave Lange who reported and did some analysis on this, we've reduced the number of LOWER( dbColumnName) LIKE 'value' to skip the LOWER part. Email is now stored as lower...
- Log in or register to post comments
A few members of the CiviCRM core team (dave, yashodha, michal and kurund) are visiting us in Nelson, NZ. We get together a couple of times a year which is quite helpful when we all return to various parts of the globe. This also gives the team a chance to visit and explore new places.
For this meeting, we decided to focus on improving a couple of things for the CiviCRM v2.1 release. The projects we decided to focus on are: AJAX widgets, Unit Testing, Component Architecture and Events. We focussed on Dojo and AJAX for the first week. The widget that my group tackled were:
- WYSIWYG editors. Most folks were not too happy with the Dojo editor. In v2.1 we decided to give folks a choice between a couple of editors. In the 2.1 release we will give folks an option between TinyMCE and FCKEditor. There was a QuickForm extension for FCKEditor. This seemed a nice...
As hinted previously, I’ve been working on dedupe improvements for CiviCRM 2.1. The first thing I wanted to handle is to move as much of the dedupe search from the PHP code to the database side.
I created a wiki page describing the plan; it would be great if any interested parties gave it a read and commented. Thanks!
CREATE TABLE civicrm_menu (
id int unsigned NOT NULL AUTO_INCREMENT ,
domain_id int unsigned NOT NULL ,
path varchar(255)... Read more- 6 comments
- Log in or register to post comments
We’re currently planning on various improvements to the duplicate contact finding (and merging) engine for CiviCRM 2.1. Among others, we plan to have a more responsive mechanism by caching the dedupe search results in a more effective way, add the ability to restrict deduping to a certain group, as well as move at least parts of the dedupe out of PHP and into MySQL (now that we require MySQL 5 anyway).
Thus, a plea: if you have a large real-world database that you could share with us, please do so – either by sending it to shot@civicrm.org encrypted with my GPG key (0xD128F14A) or mailing me to co-ordinate some other way to share it. Your database will not be disclosed to anyone, will be used solely for CiviCRM 2.1 dedupe profiling and will be destroyed once the profiling is done.
- 4 comments
- Log in or register to post comments
Some members of the core CiviCRM team are getting together for a design and code sprint towards 2.1 in Nelson NZ from April 24th - May 8th. As part of improving CiviCRM, we'd love to get together with some CiviCRM users and learn a bit about how we can improve and make CiviCRM more effective.
Since most of that period is within the NZ school holidays, we figured that May 7th might be a good meeting date. We'd prefer to meet in Nelson, but are open to traveling to either Blenheim or Christchurch if more convenient to other folks. Please send us email or reply to this post and let us know if you can make it
Continuing the database cleanup that we started with v2.0, we are planning to drop some of the unused fields from civicrm_address table.
List of fields that will be dropped.
1. street_number
2. street_number_suffix
3. street_number_predirectional
4. street_name
5. street_type
6. street_number_postdirectional
7. street_unit
8. supplemental_address_3
These fields were originally included with the intent that they would be useful for walk-lists or other use cases where address segments were needed. However, as far as we know - no one has taken advantage of these pieces of data. Hence we are planning to drop it in v2.1. Currently you cannot add/update these fields through UI.
So if anyone wants these fields please let us know asap.
- 8 comments
- Log in or register to post comments
