Offline Symbol Table: OwnerId not correctly represented

[Derek Wiers]

Pardon if I'm misinterpreting how the offline symbol table works, but I assume that the Id field "OwnerId" in just about any given SObject should be declared like so:

global Id OwnerId;
global User Owner;

however, what I'm seeing (for at least Account):

This results in failed syntax highlighting and autocomplete (this one is for lead, hence the custom Account__r relationship):

Ultimately, it's not a huge deal, but it does reduce the automatic-ness of IC.

[Scott Wells]

You're correct about how it should be rendered into the OST. I'm seeing the following in my OST for Account:

global User Owner;
global Id OwnerId;

What is the type of the Owner field in that class? Is it User also? I imagine you've already done this, but have you tried regenerating the OST to see if the results are the same?

[Scott Wells]

I just regenerated my OST using the latest released build and verified that all Owner SObject fields have type User and all OwnerId SObject fields have type Id. Needless to say, this is actually happening to you as shown in the provided screenshot, so I'm quite curious as to why. Please let me know your findings after regenerating your OST.

[Derek Wiers]

@RoseSilverSoftware , I've actually been regenerating my OST rather often lately, because I have a lot of work recently where it's (step 1) create new field, then (step 2) use that field in code, so I only just regenerated my OST today. I'll upload my OST here in a minute for your inspection.

[Scott Wells]

Thanks. I'll take a look shortly. Since you're needing to regenerate often for new fields, are you just regenerating the SObjects or the entire thing?

[Derek Wiers]

Usually just the SObjects. It only takes a couple minutes, and I just go and grab coffee or brew my tea during that time lol

[Scott Wells]

Okay, at a glance this definitely looks suspicious. As you pointed out, I see the field OwnerId as type User, but I don't see the field Owner at all. Let me take a look this evening at how I'm generating relationship fields for system ID fields in the OST. I don't think your custom Owner_Id__c field would be causing that logic to get sideways, but something obviously is. I see the correct relationship fields for other system ID fields such as MasterRecordId and ParentId...just not OwnerId. Must be some method to the madness! I'll let you know what I find. My guess is that once I nail it, it should be very quick to fix.

Oh, and if you want to delete your attachment, feel free. I think I have what I need now to debug this.

[Derek Wiers]

thanks, I appreciate it! (all of it)

[Derek Wiers]

found another interesting artifact:

global class Lead extends SObject {
...
global SObject OwnerId;
}

I know we've established that at least in my case, OwnerId and Owner are messed up (which is of course what this issue is about) - but on top of that, "Owner", once fixed, shouldn't be an SObject - but a "Name" object, since it's a polymorphic relationship that you can still (sort of) traverse in a single SOQL query. Just worth pointing out.

[Scott Wells]

Thanks for the update, Derek. Yeah, I think I ran across that at some point and haven't addressed it yet. Hopefully I'll get to a chance to take a look at this overall issue in the next day or so (still trying to wrap up a major change to connection management right now), and when I do I'll see if I can correct this as well.

[Derek Wiers]

Hmm. Working on Opportunities and Opportunity.OpportunityLineItems (which should be seen as a List<OpportunityLineItem> on Opportunity in the OST)...that appears to flat-out not exist in my OST.

Again, not show-stopping since it still compiles just fine, I just found it kinda wacky.

[Derek Wiers]

I had just refreshed the OST (full refresh) earlier this afternoon.

Figured as this has to do with the OST (and could believably be the same issue at its core), I'd just tack it on to this ticket and you're welcome to split it out into another if you deem it separate enough.

[Scott Wells]

No problem using this issue. I did look into this briefly. It had been a LONG time since I'd looked at the OST generation code in detail...or at least the SObject generation aspect...but I thought I remembered that I got all of the field/relationship information from Salesforce's API and it looks like that's in fact the case. If you don't mind, would you check whether you see the same thing in Workbench (workbench.developerforce.com)? Go under the info menu to Standard & Custom Objects. For each of Account and Lead, expand Fields and then OwnerId. Please attach screenshots of the resulting information about those fields.

I should just be using a combination of name, relationshipName, and referenceTo to build up the fields. Now don't get me wrong...it's very possible (likely even) that this is a bug on my part, but since I don't have access to the org where this is happening, and since I haven't ever seen it happen for anyone else, let's rule out an issue at the source first if you don't mind.

[Derek Wiers]

No offense taken; eliminating possibilities where possible is part of the job, and I agree with you something's fishy and I wouldn't rule out my org just yet. Opportunity.OpportunityLineItems is confirmed to show up in Workbench though (see screenshot)

[Derek Wiers]

...And here's the Lead.OwnerId bit you asked for as well.

[Scott Wells]

Thanks, Derek. Unless there's any safe way that I could connect to this org long enough to try to generate an OST (and I imagine that I absolutely could not which is totally fine...doesn't hurt to ask, though), I think I'll need to instrument the SObject generation stuff VERY heavily with debug logging, provide you a diagnostic build, and get the resulting logs. This is definitely a curious issue...

[Derek Wiers]

I'm guessing (correct me if I'm wrong) that you can see my email address from my user profile here on BitBucket. Could you send me an email and we can talk more privately from there regarding this? The short answer is yes, there is a way (with my boss' blessing) for me to give you read-only access to my developer sandbox (which is also exhibiting this issue).

[Scott Wells]

Derek, I can't see your email address, but you can shoot me a note at [e-mail] to kick off the conversation. Thanks!

[Piotr Kożuchowski]

There is identical issue with Product2Id field on PricebookEntry, Product2Id is resolved as relation field instead of id.

// Generated by Illuminated Cloud on Mon Feb 06 14:41:16 CET 2017. Do not edit.

global class PricebookEntry extends SObject 
{
    global List<ContractLineItem> ContractLineItems;
    global Boolean IsActive;
    global List<OpportunityLineItem> OpportunityLineItems;
    global List<OrderItem> OrderItems;
    global Pricebook2 Pricebook2Id;
    global Product2 Product2Id;
    global String ProductCode;
    global List<QuoteLineItem> QuoteLineItems;
    global SObjectType SObjectType;
    global Datetime SystemModstamp;
    global Currency UnitPrice;
    global Boolean UseStandardPrice;

    global PricebookEntry()
    {
    }
}

[Scott Wells]

Okay, I'm attaching a test build that has been heavily instrumented for OST SObject generation debug logging. To enable it, add the following to Help>Debug log settings:

#com.illuminatedcloud.symtab.OfflineSymbolTable

Regenerate the SObjects-only portion of your OST. Because the logging is so verbose, you'll need to gather all logs from that timeframe and send them to me (feel free to use email instead of attaching here assuming they contain sensitive info). Hopefully the smoking gun will be in those logs.

[Derek Wiers]

@RoseSilverSoftware , dumb question, how do I go about installing the test build? (I'm not as familiar with the IntelliJ environment as I'd like). For reference, I'm on a mac.

Thanks!

[Scott Wells]

Not a dumb question at all! Download the attached .zip file into your local filesystem, then from IntelliJ IDEA use Settings>Plugins>Install plugin from disk to install it. After the IDE restart it'll be using that build. Let me know if that doesn't do it for you.

[Scott Wells]

Okay, I've just submitted a fix. There were two small bugs related to this that only kicked in when you had a standard relationship field in a local .object file during OST generation. I'll include the fix in the next release.

[Scott Wells]

Delivered in 1.7.8.6. If the OST doesn't look correct after upgrading/regenerating (minimally SObjects), please let me know.