Skip navigation
All Places > Developer > Blog > 2018 > July
2018

We're doing something new at SugarCon this year, and we want you to be a part of it!  During happy hour on the first night of the conference, we're hosting a series of lightning talks for our developers. 

 

These lightning talks are going to be five minutes long, consisting of 20 slides that automatically advance every 15 seconds.  You can learn more about this exciting talk format in the video below!

 

Whether you're brand new to public speaking or a seasoned speaker, this is a great way to share your story, add to your speaker's resume, and build your personal brand.  Attendees will be sipping cocktails and ready to cheer you on! 

 

Our call for proposals is open now until Tuesday, August 21, 2018.  Submit your ideas here

 

We look forward to hearing your story!

This blog by SugarCRM Technical Account Manager and Solution Architect Angel Magana is reposted with his permission. See Angel's Blog: SugarCRM: Related Data Interactions for the original post from Angel's blog. In this post, Angel explains some best practices for working with related records in PHP that can help improve performance of your customization.

Fetching related records

 

Often times a customization we are working on requires us to interact with related data, usually records that have a parent-child relationship with one another. For example, a customization might require us to determine if a given Account record has 1 or more related Contacts. Or for that matter, we may need the collection of ID values that represent all the Calls linked to a Contact.

 

In either example, the path most often followed could be described with the following pseudo-code:

 

1. Instantiate the parent SugarBean object (e.g. Account/Contact record object)
2. Load the corresponding relationship to access the related data objects
3. Retrieve the related SugarBean objects representing the related objects

 

See below for a PHP snippet illustrating the above:

 

<?php 

//Some other code

//Instantiate parent record SugarBean object
$ParentBean = BeanFactory::retrieveBean('Accounts', 'some_account_id_value');

//Load the pertinent relationship using Link field name
$ParentBean->load_relationship('contacts');

//Retrieve related Contact(s) SugarBean object(s)
$RelatedContacts = $ParentBean->contacts->getBeans();

//The rest of our code


Line 12 in the above example would effectively create an array of SugarBean objects representing the linked Contacts. From that point forward, determining whether or not the Account has any linked Contacts becomes a simple matter of checking the size of the array. 

 

For the linked Calls example, the code would be very similar, except we would load the 'calls' relationship and the ID values we want would be in the SugarBean object array that results from executing the getBeans() method.

 

Do you need full Beans or just the IDs?

 

Now, all of the above would function just fine, but let us consider a few things about this approach.

 

First, upon executing the getBeans() method, we are asking Sugar to retrieve the complete SugarBean object for all the related records of a given type. However, for both examples, simply retrieving the ID value would have sufficed.

 

That is, for our purposes, a list of ID values in the $RelatedContacts array is just as good as an array of all the SugarBean objects. That array would still allow us to properly answer the question of whether there are or are not any linked contacts, solely based on the number of ID value entries the array contains.

 

In the case of the second example, we specifically only need the ID values of the related Calls, but getBeans() gives us everything pertaining to each of those calls. This tells us there is a lot of overhead we can trim.

 

From a performance standpoint, anytime we can optimize our code to retrieve only what we need, we help minimize wait times a user experiences. 

 

How do we then change our code to only give us the ID values?

 

It is actually a quite simple.

 

<?php 

//Some other code

//Instantiate parent record SugarBean object
$ParentBean = BeanFactory::retrieveBean('Accounts', 'some_account_id_value');

//Load the pertinent relationship using Link field name
$ParentBean->load_relationship('contacts');

//Retrieve related Contact(s) IDs ONLY.
$RelatedContacts = $ParentBean->contacts->get();

//The rest of our code

 

Examining the Link2 class in Sugar reveals a get() method which specifically only returns ID values of related data. Using get() in place of getBeans() would allow us to achieve the goal described in our examples and also reduce the performance overhead.

 

Side note: A similar method exists in the TeamSet class, named getTeamIds(), to retrieve the ID values of Teams that compose a TeamSet, without needing to retrieve all of the Team SugarBean objects. Also be aware that get() will return all records, irrespective of team assignments on the related records. 

Hey there, developers!  We've officially released Summer '18 !  This is our fourth quarterly release for Sugar Cloud (formerly known as Sugar On-Demand).  Can you believe we now have a full year of quarterly releases?  

 

This release has a ton of great features including an updated login page, built-in support for double opt-in (think GDPR and data privacy!), emoji support , over 100 new built-in reports, and big improvements to advanced workflow.

 

Our Co-Founder & CMO, Clint Oram, discusses the highlights of this release from an end-user's perspective in the video below: 

 

 

Matt Marum and I recently hosted a webinar where we gave an overview of the big things developers need to know about this release: 

 

The slides from the webinar are available here.

 

If you're looking for the high-level overview, I've got you covered!

  • We have updated the Login page to display new content, so you'll want to make sure any customizations you made to the Login page still work.
  • Sugar now supports emoji!  You can get the details in Matt's blog post  
  • The GDPR and data privacy are hot topics, and that's why we have added to our existing data privacy features to support double opt-in.
  • We created a new ReportSchedules module that utilizes Sidecar.  If you have customized the old BWC report scheduling view, you'll need to reimplement those customizations for the new ReportSchedules module.
  • You can now export and import all business rules and email templates used in a process definition.  You no longer have to worry about manually reconfiguring pieces of your process definition when moving between environments.
  • We will be posting this release in the Developer Builds community so you can do your development locally.

 

This blog post promised to have just about everything you need to know about the Summer '18 release.  Below are some resources that have the rest of the details.

 

We hope you’re as excited about this release as we are!