Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom objectId not working when there is a cloud function trigger "beforeSave" #128

Closed
lsmilek1 opened this issue Apr 25, 2021 · 3 comments
Labels
type:question Support or code-level question

Comments

@lsmilek1
Copy link
Contributor

lsmilek1 commented Apr 25, 2021

Hello, I am not sure if this is related to ParseSwift of rather the Sever itself, but when I use following function in Cloud Code, my custom objectId is ignored upon saving a new document to database:

Parse.Cloud.beforeSave("PrsProfile", async (request) => {
    if (request.original == null) {
        //indexing to ElasticSearch before save to define ElasticSearch document id
        const esResult = await elastic.indexProfile(request.object);
        if (esResult != null) {
            request.object.set("es", esResult);
            const randomInt = Math.floor(Math.random() * (262144 - 1)) + 1; //bloom filter index in range 1...262144 (256*1024)
            request.object.set("bf", randomInt);
            request.log.info(`indexed new profile before saving to server database: ${esResult}}`);
        } else {
            throw "ElasticSearch ID was not defined, document was not saved and indexed";
        }
    }
});

As the function does not manipulate objectId neither the referred index function, I am a bit confused. Commenting out this trigger makes the custom objectId work well again. Also trigger "afterSave" does not break anything.

Just for completeness, here is the referred index function:

exports.indexProfile = async function(profile) { //PrsProfile
    const currentLoc = new Parse.GeoPoint(profile.get("gp"));
    const speakLangs = [];
    const native = profile.get("nl");
    const speak = profile.get("sl");
    const learnLangs = profile.get("ll");
    const trips = profile.get("gt");
    if (native != null & Array.isArray(native)) {
        speakLangs.push(...native);
    }
    if (speak != null & Array.isArray(speak)) {
        speakLangs.push(...speak);
    }
    const { body } = await esClient.index({        
        id: profile.get("es"), //if null, then new index is created
        index: "profile",
        body: {
            //TODO: check how updates are handeled
            ag: profile.get("ag"),
            gn: profile.get("gn"),
            d: profile.get("d"),
            o: profile.get("o"),
            po: profile.get("po"),
            sl: (speakLangs.length > 0 ? speakLangs : []), 
            ll: ((learnLangs != null & Array.isArray(learnLangs)) ? learnLangs : []),
            gp: [currentLoc.latitude, currentLoc.longitude], 
            on: profile.get("on"), 
            da: profile.get("da"), 
            tn: profile.get("tn"), 
            tr: profile.get("tr"), 
            co: profile.get("co"), 
            gt: ((trips != null & Array.isArray(trips)) ? trips : []), 
            fd: profile.get("fd"),
            bf: profile.get("bf") //bloom filter int value
        }
    })
    //pass back an ES document id to be saved in MongoDB, if creating new
    return body._id;
}

@lsmilek1
Copy link
Contributor Author

I believe it is related to this open issue. If you agree, feel free to close this one. Thank you!

@cbaker6
Copy link
Contributor

cbaker6 commented Apr 25, 2021

As the function does not manipulate objectId neither the referred index function, I am a bit confused. Commenting out this trigger makes the custom objectId work well again. Also trigger "afterSave" does not break anything.

If commenting out the trigger allows your custom objectId to save correctly then it sounds like the issue is either with your cloud code or the server. I don't see the Swift Client SDK having any influence when it gets to your cloud code

@cbaker6
Copy link
Contributor

cbaker6 commented Apr 25, 2021

I believe it is related to this open issue. If you agree, feel free to close this one. Thank you!

It looks like that may be the issue and I see someone posted a workaround.

I recommend moving your original comment to the issue thread you found so the server team can see it's still an open issue

@mtrezza mtrezza added type:question Support or code-level question and removed invalid labels Sep 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:question Support or code-level question
Projects
None yet
Development

No branches or pull requests

3 participants