- Identify areas of opportunity (customizations that can be further refined or optimized)
- Catalog potential pitfalls one may encounter were the instance upgraded
A challenge posed by such reviews is that any given instance can include customizations that touch a wide variety of the framework features and in different ways. Despite this, certain patterns emerge that point at common habits that require some level of attention and are applied while customizing Sugar. The more common behaviors are discussed in this post in hopes they will help you avoid some frustrations.
1. Incomplete WHERE clauses. SugarQuery is the preferred mechanism for querying the Sugar database programmatically. However, executing an ad-hoc query is sometimes unavoidable. For such scenarios, always remember that Sugar performs soft deletes of its data. Thus, when attempting to interact with "active" records in the database, one must add the deleted = 0 condition to the WHERE clause, or run the risk of working with dirty data. This requirement spans across nearly all tables in the Sugar database, including the relationship tables such as accounts_contacts. Below is an example of its use:
SELECT * FROM contacts WHERE first_name = 'Angel' AND deleted = 0;
2. Using database platform specific features. Expanding on the previous point, the use of raw SQL queries is sometimes unavoidable. Should you find yourself in such a scenario, bear in mind the intended scope of your customization. If you intend for your customization to reach a large number of Sugar instances, avoid using database platform specific features as doing so will automatically cause your customization to only work on a single database platform.