CRUD ਐਪਾਂ ਵਿੱਚ ਰੇਸ-ਕੰਡਿਸ਼ਨ: ਕਾਰਨ ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਸੁਧਾਰ

CRUD ਐਪ ਵਿੱਚ ਰੇਸ-ਕੰਡਿਸ਼ਨ ਕਿਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ

ਰੇਸ-ਕੰਡਿਸ਼ਨ ਉਸ ਸਮੇਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਦੋ (ਜਾਂ ਵੱਧ) ਰਿਕਵੇਸਟ ਇੱਕੋ ਹੀ ਡੇਟਾ ਨੂੰ ਲਗਭਗ ਇਕੋ ਹੀ ਸਮੇਂ ਅੱਪਡੇਟ ਕਰਦੇ ਹਨ, ਅਤੇ ਆਖਰੀ ਨਤੀਜਾ ਟਾਈਮਿੰਗ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ। ਹਰ ਰਿਕਵੇਸਟ ਆਪਣੇ ਆਪ ਵਿੱਚ ਠੀਕ ਲੱਗਦੀ ਹੈ। ਪਰ ਇੱਕੱਠੇ ਹੋ ਕੇ ਗਲਤ ਨਤੀਜਾ ਨਿਕਲਦਾ ਹੈ।

ਸਧਾਰਨ ਉਦਾਹਰਨ: ਦੋ ਲੋਕ ਇਕੋ ਗਾਹਕ ਰਿਕਾਰਡ 'ਤੇ ਇੱਕ ਸਕਿੰਟ ਦੇ ਅੰਦਰ "ਸੇਵ" ਦਬਾਉਂਦੇ ਹਨ। ਇਕ ਇਮੇਲ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਫ਼ੋਨ ਨੰਬਰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ। ਜੇ ਦੋਹਾਂ ਰਿਕਵੇਸਟਰਾਂ ਨੇ ਪੂਰਾ ਰਿਕਾਰਡ ਭੇਜਿਆ, ਤਾਂ ਦੂਜੀ ਲਿਖਤ ਪਹਿਲੀ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਇੱਕ ਬਦਲਾਅ ਬਿਨਾਂ ਕਿਸੇ ਐਰਰ ਦੇ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇਹ ਤੇਜ਼ ਐਪਾਂ ਵਿੱਚ ਵੱਧ ਦੇਖਣ ਨੂੰ ਮਿਲਦਾ ਹੈ ਕਿਉਂਕਿ ਉਪਭੋਗਤਾ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਵੱਧ ਕਾਰਵਾਈਆਂ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਵਾਰ-ਵਾਰ ਵੱਧ ਲੋਡ ਵਾਲੇ ਪਲਾਂ 'ਤੇ ਵੀ ਵਧ ਜਾਂਦਾ ਹੈ: ਫਲੈਸ਼ ਸੇਲ, ਮਹੀਨੇ ਦੇ ਅੰਤ ਦਾ ਰਿਪੋਰਟਿੰਗ, ਵੱਡਾ ਇਮੇਲ ਕੈਂਪੇਨ, ਜਾਂ ਜਦੋਂ ਰਿਕਵੇਸਟਾਂ ਦੀ ਭਾਰਹਵਾ ਇਕੇ ਹੀ ਰੋਜ਼ਾਂ 'ਤੇ ਪੈਂਦੀ ਹੈ।

ਉਪਭੋਗਤਾ ਜ਼ਿਆਦਾਤਰ ਵਾਰ "ਰੇਸ-ਕੰਡਿਸ਼ਨ" ਦੀ ਸ਼ਿਕਾਇਤ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਲੱਛਣ ਦਰਜ ਕਰਦੇ ਹਨ: ਡੁਪਲਿਕੇਟ ਆਰਡਰ ਜਾਂ ਕਮੈਂਟ, ਗੁੰਮ ਅੱਪਡੇਟ ("ਮੈਂ ਸੇਵ ਕੀਤਾ, ਪਰ ਵਾਪਸ ਆ ਗਿਆ"), ਅਜੀਬ ਟੋਟਲ (ਇਨਵੈਂਟਰੀ ਨੈਗੇਟਿਵ ਹੋ ਜਾਦੀ ਹੈ, ਕਾਊਂਟਰ ਬੈਕਵਰਡ ਜੰਪ ਕਰਦੇ ਹਨ), ਜਾਂ ਸਥਿਤੀਆਂ ਜੋ ਅਚਾਨਕ ਫਲਿਪ ਹੋ ਜਾਂਦੀਆਂ ਹਨ (ਮੰਨਜ਼ੂਰ ਹੋਈ, ਫਿਰ ਫਿਰ ਤੋਂ ਪੈਂਡਿੰਗ)।

ਰੀਟ੍ਰਾਈਜ਼ ਇਸਨੂੰ ਹੋਰ ਖਰਾਬ ਕਰ ਦਿੰਦੇ ਹਨ। ਲੋਕ ਡਬਲ-ਕਲਿੱਕ ਕਰਦੇ ਹਨ, ਦੇਰ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਆਉਣ 'ਤੇ ਰੀਫ੍ਰੈਸ਼ ਕਰਦੇ ਹਨ, ਦੋ ਟੈਬ ਤੋਂ ਜਮ੍ਹਾਂ ਕਰਦੇ ਹਨ, ਜਾਂ ਫਲੇਕੀ ਨੈਟਵਰਕ ਕਾਰਨ ਬ੍ਰਾਊਜ਼ਰ/ਮੇਬਾਇਲ ਐਪ ਰਿਕਵੇਸਟ ਮੁੜ ਭੇਜਦਾ ਹੈ। ਜੇ ਸਰਵਰ ਹਰ ਰਿਕਵੇਸਟ ਨੂੰ ਨਵੀਂ ਲਿਖਤ ਵਜੋਂ ਸਮਝੇ, ਤਾਂ ਤੁਸੀਂ ਦੋ ਬਣਾਉ, ਦੋ ਭੁਗਤਾਨ, ਜਾਂ ਇਕ ਵਾਰੀ ਹੋਣ ਵਾਲੀ ਸਥਿਤੀ ਦੇ ਦੋ ਬਦਲਾਅ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

ਰੇਸ-ਕੰਡਿਸ਼ਨ ਅਕਸਰ ਹੋਣ ਦੇ ਕਾਰਨ

ਜ਼ਿਆਦਾਤਰ CRUD ਐਪ ਸਧਾਰਨ ਲੱਗਦੇ ਹਨ: ਇੱਕ ਰੋਅ ਪੜ੍ਹੋ, ਇੱਕ ਫੀਲਡ ਬਦਲੋ, ਸੇਵ ਕਰੋ। ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਟਾਈਮਿੰਗ ਨੂੰ ਕੰਟਰੋਲ ਨਹੀਂ ਕਰਦੀ। ਡਾਟਾਬੇਸ, ਨੈਟਵਰਕ, ਰੀਟ੍ਰਾਈਜ਼, ਬੈਕਗ੍ਰਾਊਂਡ ਕੰਮ ਅਤੇ ਉਪਭੋਗਤਾ ਦਾ ਵਿਹਾਰ ਇਹ ਸਭ ਇਕੱਠੇ ਹੋ ਸਕਦੇ ਹਨ।

ਇੱਕ ਆਮ ਟ੍ਰਿੱਗਰ ਦੋ ਲੋਕ ਇੱਕੋ ਹੀ ਰਿਕਾਰਡ ਨੂੰ ਐਡਿਟ ਕਰ ਰਹੇ ਹਨ। ਦੋਹਾਂ ਇੱਕੋ "ਮੌਜੂਦਾ" ਮੁੱਲ ਲੋਡ ਕਰਦੇ ਹਨ, ਦੋਹਾਂ ਵੈਧ ਬਦਲਾਅ ਕਰਦੇ ਹਨ, ਅਤੇ ਆਖਰੀ ਸੇਵ ਚੁੱਪ ਚਾਪ ਪਹਿਲੀ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਦਿੰਦੀ ਹੈ। ਕਿਸੇ ਨੇ ਵੀ ਗਲਤ ਨਹੀਂ ਕੀਤਾ, ਪਰ ਇੱਕ ਅੱਪਡੇਟ ਖੋ ਗਿਆ।

ਇਹ ਇੱਕ ਵਿਅਕਤੀ ਨਾਲ ਵੀ ਹੁੰਦਾ ਹੈ। ਸੇਵ ਬਟਨ 'ਤੇ ਡਬਲ ਕਲਿੱਕ, ਬੈਕ-ਫੌਰਵਰਡ ਟੈਪ, ਜਾਂ ਧੀਮੀ ਕਨੈਕਸ਼ਨ ਜਿਸ ਕਰਕੇ ਕੋਈ ਦੁਬਾਰਾ ਸਬਮਿਟ ਕਰ ਦੇਂਦਾ ਹੈ—ਇਹ ਸਭ ਇੱਕੋ ਲਿਖਤ ਦੋ ਵਾਰੀ ਭੇਜ ਸਕਦੇ ਹਨ। ਜੇ ਐਂਡਪਾਇੰਟ ਆਇਡੈਂਟੋਟੈਂਟ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਡੁਪਲਿਕੇਟ, ਦੁੱਗਣੇ ਚਾਰਜ, ਜਾਂ ਦੋ ਕਦਮ ਅੱਗੇ ਸਥਿਤੀ ਵੇਖ ਸਕਦੇ ਹੋ।

ਆਧੁਨਿਕ ਵਰਤੋਂ ਹੋਰ ਤਰ੍ਹਾਂ ਆਵਾਜਾਈ ਵਧਾ ਦਿੰਦੀ ਹੈ। ਇਕੋ ਅਕਾਊਂਟ ਨਾਲ ਕਈ ਟੈਬ ਜਾਂ ਡਿਵਾਈਸ ਸੰਚਾਲਿਤ ਹੋ ਸਕਦੇ ਹਨ। ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ (ਈਮੇਲ, ਬਿਲਿੰਗ, ਸਿੰਕ, ਕਲੀਨਅੱਪ) ਉਹੀ ਰੋਜ਼ਾਂ ਛੁਹ ਸਕਦੇ ਹਨ ਜੋ ਵੈੱਬ ਰਿਕਵੇਸਟ ਛੁਹਦੇ ਹਨ। ਕਲਾਇੰਟ, ਲੋਡ ਬੈਲੈਂਸਰ ਜਾਂ ਜੌਬ ਰੰਨਰ 'ਤੇ ਆਟੋਮੈਟਿਕ ਰੀਟ੍ਰਾਈ ਵੀ ਪਹਿਲਾਂ ਹੀ ਸਫ਼ਲ ਹੋ ਚੁੱਕੀ ਰਿਕਵੇਸਟ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਫੀਚਰ ਸ਼ਿੱਪ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕੋ ਹੀ ਰਿਕਾਰਡ ਨੂੰ ਯਾਦਾਂ ਤੋਂ ਵੱਧ ਥਾਂ ਤੋਂ ਅਪਡੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਿਆ ਚੈਟ-ਚਲਿਤ ਬਿਲਡਰ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਐਪ ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਸਕਦੀ ਹੈ—ਇਸ ਲਈ ਸਮਕਾਲੀਤਾ ਨੂੰ ਇੱਕ ਆਮ ਬਰਤਾਓ ਮੰਨਣਾ ਚੰਗਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਐਜ ਕੇਸ।

ਆਮ ਟਕਰਾਅ-ਬਿੰਦੂ ਜਿਨ੍ਹਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ

ਰੇਸ-ਕੰਡਿਸ਼ਨ ਅਕਸਰ "ਰਿਕਾਰਡ ਬਣਾਈਏ" ਡੈਮੋ ਵਿੱਚ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੇ। ਇਹ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਆਉਂਦੇ ਹਨ ਜਿੱਥੇ ਦੋ ਰਿਕਵੇਸਟ ਇੱਕੋ ਹੀ ਸੱਚਾਈ ਦਾ ਹਿੱਸਾ ਲਗਭਗ ਇਕੋ ਵਕਤ ਛુਹਦੇ ਹਨ। ਆਮ ਹਾਟਸਪੌਟ ਜਾਣ ਕੇ ਤੁਸੀਂ ਪਹਿਲੋ ਦਿਨ ਤੋਂ ਹੀ ਸੁਰੱਖਿਅਤ ਲਿਖਤ ਡਿਜ਼ਾਈਨ ਕਰ ਸਕਦੇ ਹੋ।

ਗਿਣਤੀ ਅਤੇ "ਅਗਲਾ ਨੰਬਰ" ਫੀਲਡ

ਜੋ ਕੁਝ ਵੀ "ਸਿਰਫ +1 ਕਰੋ" ਵਾਂਗ ਲੱਗਦਾ ਹੈ ਉਹ ਲੋਡ ਹੇਠ ਟੁੱਟ ਸਕਦਾ ਹੈ: ਲਾਈਕ, ਵਿਊ ਕਾਉਂਟ, ਟੋਟਲ, ਇਨਵਾਇਸ ਨੰਬਰ, ਟਿਕਟ ਨੰਬਰ। ਖ਼ਤਰਨਾਕ ਪੈਟਰਨ ਹੈ: ਵੈੱਲ ਪੜ੍ਹੋ, ਜੋੜੋ, ਫਿਰ ਵਾਪਸ ਲਿਖੋ। ਦੋ ਰਿਕਵੇਸਟ ਇਕੋ ਸ਼ੁਰੂਆਤੀ ਮੁੱਲ ਪੜ੍ਹ ਸਕਦੇ ਹਨ ਅਤੇ ਆਪਣੇ-ਆਪਣੇ ਨਤੀਜੇ ਲਿਖ ਦਿੱਤੇ ਜਾਣ।

ਸਥਿਤੀ ਟਰਾਂਜ਼ੀਸ਼ਨ

ਡ੍ਰਾਫਟ -> ਸਬਮਿਟਿਡ -> ਅਪ੍ਰੂਵਡ -> ਭੁਗਤਾਨ ਵਰਗੇ ਵਰਕਫ਼ਲੋ ਸੌਖੇ ਲੱਗਦੇ ਹਨ, ਪਰ ਟਕਰਾਅ ਆਮ ਹਨ। ਮੁਸੀਬਤ ਉਸ ਵੇਲੇ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਦੋ ਕਾਰਵਾਈਆਂ ਇੱਕੋ ਵਾਰੀ ਸੰਭਵ ਹੁੰਦੀਆਂ ਹਨ (ਮੰਜ਼ੂਰ ਅਤੇ ਸੋਧ, ਰੱਦ ਅਤੇ ਭੁਗਤਾਨ)। ਬਿਨਾਂ ਗਾਰਡਾਂ ਦੇ, ਤੁਸੀਂ ਇੱਕ ਐਸਾ ਰਿਕਾਰਡ ਪਾ ਸਕਦੇ ਹੋ ਜੋ ਕਦਮ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਵਾਪਸ ਫਲਿਪ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਵੱਖ-ਵੱਖ ਟੇਬਲਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਸਥਿਤੀ ਦਿਖਾਉਂਦਾ ਹੈ।

ਸਥਿਤੀ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਠੇਕੇ ਵਾਂਗੋ ਸੌਧੋ: ਕੇਵਲ ਅਗਲਾ ਵੈਧ ਕਦਮ ਐਲਾਉ ਕਰੋ ਅਤੇ ਹੋਰ ਕੁਝ ਮਨਜ਼ੂਰ ਨਾ ਕਰੋ।

ਇਨਵੈਂਟਰੀ, ਸਮਰੱਥਾ, ਅਤੇ ਬੁਕਿੰਗ ਸਲੌਟ

ਬਾਕੀ ਬੈਠਣੀਆਂ, ਸਟੌਕ ਕਾਊਂਟ, ਅਪਾਇੰਟਮੈਂਟ ਸਲੌਟ, ਅਤੇ "ਰਹਿ ਗਈ ਸਮਰੱਥਾ" ਫੀਲਡਸ ਓਵਰਸੈਲ ਦੀ ਕਲਾਸਿਕ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਦੋ ਬਾਇਰ ਇੱਕੋ ਸਮੇਂ ਚੈਕਆਉਟ ਕਰਦੇ ਹਨ, ਦੋਹਾਂ availability ਦੇਖਦੇ ਹਨ, ਅਤੇ ਦੋਹਾਂ ਸਫਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਜੇ ਡਾਟਾਬੇਸ ਅੰਤਿਮ ਫੈਸਲਾ ਕਰਨ ਵਾਲਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਅੰਤ ਵਿੱਚ ਤੁਸੀਂ ਵੱਧ ਵੇਚ ਦਿਓਗੇ।

ਯੂਨੀਕਨੈਸ ਅਤੇ "ਕੇਵਲ ਇਕ ਐਕਟਿਵ ਚੀਜ਼" ਨਿਯਮ

ਕੁਝ ਨਿਯਮ ਪੱਕੇ ਹੁੰਦੇ ਹਨ: ਪ੍ਰਤੀ ਅਕਾਊਂਟ ਇੱਕ ਇਮੇਲ, ਪ੍ਰਤੀ ਯੂਜ਼ਰ ਇੱਕ ਐਕਟਿਵ ਸਬਸਕ੍ਰਿਪਸ਼ਨ, ਪ੍ਰਤੀ ਯੂਜ਼ਰ ਇੱਕ ਖੁਲਾ ਕਾਰਟ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਚੈੱਕ ਕਰਦੇ ਹੋ ("ਕੀ ਕੋਈ ਹੈ?") ਅਤੇ ਫਿਰ ਇੰਸਰਟ ਕਰਦੇ ਹੋ। ਕੁਨਕਰਨਸੀ ਹੇਠ, ਦੋ ਰਿਕਵੇਸਟ ਦੋਹਾਂ ਚੈੱਕ ਪਾਸ ਕਰ ਸਕਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ CRUD ਫਲੋ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, Koder.ai ਵਿੱਚ ਚੈਟ ਕਰਕੇ), ਤਾਂ ਇਹ ਹਾਟਸਪੌਟ ਪਹਿਲਾਂ ਤੋਂ ਲਿਖੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ UI ਚੈਕਾਂ ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਕੰਸਟ੍ਰੇੰਟਸ ਅਤੇ ਸੁਰੱਖਿਅਤ ਲਿਖਤ ਨਾਲ ਬੈਕ ਕਰੋ।

UI ਤੋਂ ਆਉਂਦੀਆਂ ਡਬਲ ਸਬਮਿਟ ਅਤੇ ਦੁਹਰਾਈਆਂ ਰਿਕਵੇਸਟ

ਬਹੁਤ ਸਾਰੀਆਂ ਰੇਸ-ਕੰਡਿਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਇਕ ਸੁਖਾਵਣੀ ਕਾਰਨ ਨਾਲ ਹੁੰਦੀ ਹੈ: ਇਕੋ ਕਾਰਵਾਈ ਦੋ ਵਾਰੀ ਭੇਜੀ ਜਾਂਦੀ ਹੈ। ਉਪਭੋਗਤਾ ਡਬਲ-ਕਲਿੱਕ ਕਰਦੇ ਹਨ। ਨੈਟਵਰਕ ਧੀਮਾ ਹੋਣ 'ਤੇ ਉਹ ਫਿਰ ਕਲਿੱਕ ਕਰਦੇ ਹਨ। ਫ਼ੋਨ ਦੋਹਾਂ ਟੈਪ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ। ਕਦੇ-ਕਦੇ ਇਹ ਇਰਾਦਤ ਨਹੀਂ ਹੁੰਦੀ: ਪੋਸਟ ਦੇ ਬਾਦ ਪੇਜ਼ ਰੀਫ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਫਾਰਮ ਮੁੜ-ਜਮ੍ਹਾਂ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਦਿੰਦਾ ਹੈ।

ਜਦੋਂ ਇਹ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਡਾ ਬੈਕਏਂਡ ਪੈਰੱਲਲ ਤੌਰ 'ਤੇ ਦੋ ਬਣਾਉ ਜਾਂ ਅੱਪਡੇਟ ਚਲਾ ਸਕਦਾ ਹੈ। ਜੇ ਦੋਹਾਂ ਸਫਲ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਡੁਪਲਿਕੇਟ、ਗਲਤ ਟੋਟਲ、ਜਾਂ ਇੱਕ ਸਥਿਤੀ ਬਾਰ-ਬਾਰ ਚੱਲਣ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ (ਉਦਾਹਰਨ: ਇਕ ਵਾਰੀ ਮਨਜ਼ੂਰ, ਫਿਰ ਮੁੜ ਮਨਜ਼ੂਰ)। ਇਹ ਰੈਂਡਮ ਵਾਂਗ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟਾਈਮਿੰਗ 'ਤੇ ਨਿਰਭਰ ਹੈ।

ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਡੈਫੈਂਸ-ਇਨ-ਡੈਪਥ ਹੈ। UI ਨੂੰ ਠੀਕ ਕਰੋ, ਪਰ ਮੰਨੋ ਕਿ UI ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਲਿਖਤ ਫਲੋਜ਼ 'ਚ عملي تبدیلیاں ਜੋ ਤੁਸੀਂ ਲਾ ਸਕਦੇ ਹੋ:

• ਪਹਿਲੀ ਕਲਿੱਕ 'ਤੇ ਸਬਮਿਟ ਨੂੰ ਅਯੋਗ ਕਰੋ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ "ਸੇਵ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ" ਰਾਜ ਦਿਖਾਓ।
• ਸਫਲ POST ਤੋਂ ਬਾਅਦ ਰੀਡਾਇਰੈਕਟ ਕਰੋ ਤਾਂ ਕਿ ਰੀਫ੍ਰੈਸ਼ ਫਾਰਮ ਨੂੰ ਮੁੜ-ਸਬਮਿਟ ਨਾ ਕਰੇ।
• ਆਇਡੈਂਟੋਟੈਂਸੀ ਕੀ ਵਰਤੋ: ਹਰ ਉਪਭੋਗਤਾ ਕਾਰਵਾਈ ਲਈ ਇੱਕ ਵਿਲੱਖਣ ਟੋਕਨ ਜੋ ਸਰਵਰ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਕੇਵਲ ਇਕ ਵਾਰੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।
• ਇਸ ਨੂੰ ਡਾਟਾਬੇਸ ਯੂਨੀਕਨੈਸ ਰੂਲ ਨਾਲ ਬੈਕ ਕਰੋ ਤਾਂ ਕਿ ਦੋ ਸਮਾਨ ਇੰਸਰਟ ਵਿੱਚੋਂ ਦੋਹਾਂ ਨਹੀਂ ਜਿੱਤ ਸਕਦੇ।

ਉਦਾਹਰਨ: ਯੂਜ਼ਰ ਮੋਬਾਈਲ 'ਤੇ "ਚਲਾਨ ਦੀ ਭੁਗਤਾਨ ਕਰੋ" ਦਬਾਉਂਦਾ ਹੈ ਅਤੇ ਦੋ ਵਾਰੀ ਟੈਪ ਕਰਦਾ ਹੈ। UI ਨੂੰ ਦੂਜਾ ਟੈਪ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਰਵਰ ਨੂੰ ਵੀ ਦੂਜੀ ਰਿਕਵੇਸਟ ਨੂੰ ਉਸੇ ਆਇਡੈਂਟੋਟੈਂਸੀ ਕੀ ਦੇਖ ਕੇ ਰੱਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਸਲ ਸਫਲ ਨਤੀਜੇ ਨੂੰ ਮੁੜ ਵਾਪਸ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਦੁੱਗਣਾ ਚਾਰਜ ਨਾ ਹੋਵੇ।

ਅਣੁਕੂਲ ਨਾ ਰਹਿੰਦੇ ਸਥਿਤੀ ਟਰਾਂਜ਼ੀਸ਼ਨ

ਸਥਿਤੀ ਫੀਲਡ ਸਧਾਰਨ ਲੱਗਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਦੋ ਚੀਜ਼ਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇਕੱਠੇ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰਨ। ਇਕ ਯੂਜ਼ਰ Approve 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ автоматਿਕ ਜੌਬ ਉਹੀ ਰਿਕਾਰਡ Expired ਮਾਰਕ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਦੋ ਟੀਮ ਮੈਂਬਰ ਵੱਖ-ਵੱਖ ਟੈਬਾਂ 'ਚ ਕੰਮ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਦੋਹਾਂ ਅੱਪਡੇਟ ਸਫਲ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਆਖਰੀ ਸਥਿਤੀ ਤੁਹਾਡੇ ਨਿਯਮਾਂ 'ਤੇ ਨਹੀਂ, ਟਾਈਮਿੰਗ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੀ ਹੈ।

ਸਥਿਤੀ ਨੂੰ ਇੱਕ ਛੋਟੀ ਸਟੇਟ ਮਸ਼ੀਨ ਵਜੋਂ ਵਿਆਖਿਆ ਕਰੋ। ਮਨਜ਼ੂਰ ਕੀਤੇ ਗਏ ਮੂਵਾਂ ਦੀ ਇੱਕ ਛੋਟੀ ਸੂਚੀ ਰੱਖੋ (ਉਦਾਹਰਨ: Draft -> Submitted -> Approved, ਅਤੇ Submitted -> Rejected)। ਫਿਰ ਹਰ ਲਿਖਤ ਚੈੱਕ ਕਰੋ: "ਕੀ ਇਹ ਮੂਵ ਮੌਜੂਦਾ ਸਥਿਤੀ ਤੋਂ ਮਨਜ਼ੂਰ ਹੈ?" ਜੇ ਨਹੀਂ, ਤਾਂ ਇਸਨੂੰ ਰੱਦ ਕਰੋ ਬਜਾਏ ਚੁੱਪਚਾਪ ਓਵਰਰਾਈਟ ਕਰਨ ਦੇ।

Optimistic locking ਤੁਹਾਨੂੰ stale ਅੱਪਡੇਟਾਂ ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਦੂਜੇ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਰੋਕਣ ਦੇ। ਇੱਕ ਵੇਰਜ਼ਨ ਨੰਬਰ (ਜਾਂ updated_at) ਜੋੜੋ ਅਤੇ ਸੇਵ ਕਰਨ ਵੇਲੇ ਇਹ ਮੇਲ ਖਾਣਾ ਲਾਜ਼ਮੀ ਕਰੋ। ਜੇ ਕਿਸੇ ਨੇ ਉਸ row ਨੂੰ ਤੁਹਾਡੇ ਲੋਡ ਦੇ ਬਾਅਦ ਬਦਲ ਦਿੱਤਾ, ਤਾਂ ਤੁਹਾਡੀ ਅੱਪਡੇਟ 0 ਰੋਅز ਪ੍ਰਭਾਵਿਤ ਕਰੇਗੀ ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦੇ ਸਕਦੇ ਹੋ: "ਇਹ ਆਈਟਮ ਬਦਲ ਗਿਆ, ਰੀਫ੍ਰੈਸ਼ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ।"

ਸਥਿਤੀ ਅੱਪਡੇਟ ਲਈ ਇਕ ਸਾਦਾ ਪੈਟਰਨ:

• ਮੌਜੂਦਾ ਸਥਿਤੀ ਅਤੇ ਵੇਰਜ਼ਨ ਪੜ੍ਹੋ
• ਟਰਾਂਜ਼ੀਸ਼ਨ ਨੂੰ ਵੈਧਤਾ ਕਰੋ
• ਗਾਰਡ ਨਾਲ ਅੱਪਡੇਟ ਕਰੋ (WHERE status = ? AND version = ?)
• ਵੇਰਜ਼ਨ ਨੂੰ ਵੱਧ ਕਰੋ

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਥਿਤੀ ਬਦਲਾਅ ਇੱਕ ਥਾਂ 'ਤੇ ਰੱਖੋ। ਜੇ ਅੱਪਡੇਟ ਸਕ੍ਰੀਨਾਂ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਾਂ ਅਤੇ webhookਸ 'ਚ ਤੇਰ-ਤੇਰ ਫੈਲੇ ਹੋਏ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਕੋਈ ਨਿਯਮ ਗੁਆ ਲਓਗੇ। ਉਹਨਾਂ ਨੂੰ ਇਕ ਫੰਕਸ਼ਨ ਜਾਂ ਐਂਡਪਾਇੰਟ ਦੇ ਅੰਦਰ ਰੱਖੋ ਜੋ ਹਰ ਵਾਰੀ ਇੱਕੋ ਜਿਹੇ ਟਰਾਂਜ਼ੀਸ਼ਨ ਚੈੱਕ ਲਗਾਉਂਦਾ ਹੈ।

ਸਮੇਂ ਦੇ ਨਾਲ ਕਾਊਂਟਰ ਅਤੇ ਟੋਟਲ ਡ੍ਰਿਫ ਹੋਣਾ

ਸਭ ਤੋਂ ਆਮ ਕਾਊਂਟਰ ਬੱਗ ਨਿਰਦੋਸ਼ ਲੱਗਦਾ ਹੈ: ਐਪ ਇੱਕ ਮੁੱਲ ਪੜ੍ਹਦਾ ਹੈ, +1 ਕਰਦਾ ਹੈ, ਫਿਰ ਵਾਪਸ ਲਿਖਦਾ ਹੈ। ਲੋਡ ਹੇٺ, ਦੋ ਰਿਕਵੇਸਟ ਇਕੋ ਨੰਬਰ ਪੜ੍ਹ ਸਕਦੇ ਹਨ ਅਤੇ ਦੋਹਾਂ ਇੱਕੋ ਨਵਾਂ ਨੰਬਰ ਲਿਖ ਦੇਂਦੇ ਹਨ, ਇਸ ਤਰ੍ਹਾਂ ਇੱਕ ਇੰਕ੍ਰੀਮੈਂਟ ਖੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਟੈਸਟਿੰਗ ਚ "ਅਕਸਰ ਕੰਮ ਕਰਦਾ" ਇਸ ਲਈ ਆਸਾਨੀ ਨਾਲ ਛੱਡਿਆ ਜਾਂਦਾ ਹੈ।

ਪੜ੍ਹੋ-ਫਿਰ-ਲਿਖੋ ਦੀ ਥਾਂ ਐਟੋਮਿਕ ਅਪਡੇਟ ਪ੍ਰੀਫਰ ਕਰੋ

ਜੇ ਕੋਈ ਮੁੱਲ ਕੇਵਲ ਇੰਕ੍ਰੀਮੈਂਟ ਜਾਂ ਡੀਕ੍ਰੀਮੈਂਟ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਡਾਟਾਬੇਸ ਨੂੰ ਇਕ ਵਰਕ ਵਿੱਚ ਇਹ ਕਰਵਾ ਦਿਓ। ਇਸ ਤਰ੍ਹਾਂ ਡਾਟਾਬੇਸ ਬਹੁਤ ਸਾਰੇ ਰਿਕਵੇਸਟਾਂ ਦੇ ਹਿੱਟ ਹੋਣ 'ਤੇ ਵੀ ਬਦਲਾਅ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰੇਗਾ।

UPDATE posts
SET like_count = like_count + 1
WHERE id = $1;

ਇਹੀ ਵਿਚਾਰ ਇਨਵੈਂਟਰੀ, ਵਿਊ ਕਾਉਂਟ, ਰੀਟ੍ਰਾਈ ਕਾਊਂਟਰ ਅਤੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜੋ "ਨਵਾਂ = ਪੁਰਾਣਾ + ਡੈਲਟਾ" ਵਜੋਂ ਪ੍ਰਗਟ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ ਜੋ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹੋ ਉਹ ਸਟੋਰ ਕਰ ਲੈਂਦੇ ਹੋ ਤਾਂ ਟੋਟਲ ਡ੍ਰਿਫ ਹੁੰਦੇ ਹਨ

ਟੋਟਲ ਅਕਸਰ ਗਲਤ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰਾਪਤ ਨੰਬਰ (order_total, account_balance, project_hours) ਸਟੋਰ ਕਰਦੇ ਹੋ ਅਤੇ ਫਿਰ ਉਸਨੂੰ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ ਤੋਂ ਅਪਡੇਟ ਕਰਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਟੋਟਲ ਨੂੰ ਸਰੋਤ ਰੋਅਜ਼ (line items, ledger entries) ਤੋਂ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਡ੍ਰਿਫ ਬੱਗਾਂ ਤੋਂ ਬਚ ਜਾਂਦੇ ਹੋ।

ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਸਪੀਡ ਲਈ ਟੋਟਲ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ ਇਕ ਨਾਜੁਕ ਲਿਖਤ ਸਮਝੋ। ਸਾਰੀਆਂ ਸੋਰਸ ਰੋਅਜ਼ ਅਤੇ ਸਟੋਰ ਕੀਤੇ ਟੋਟਲ ਨੂੰ ਇੱਕੋ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਰੱਖੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ אותו ਟੋਟਲ 'ਤੇ ਇੱਕੋ ਸਮੇਂ ਕੇਵਲ ਇੱਕ ਹੀ ਲਿਖਨਹਾਰ ਹੋ ਸਕਦਾ (ਲਾਕਿੰਗ, ਗਾਰਡ ਕੀਤੇ ਅਪਡੇਟ, ਜਾਂ ਇੱਕੋ ਮਾਲਕ ਰਸਤਾ)। ਅਨਲੋਕੇ সম্ভব ਕੀਮਤਾਂ ਨੂੰ ਰੋਕਣ ਵਾਲੇ ਕੰਸਟ੍ਰੇੰਟ ਜੋੜੋ (ਉਦਾਹਰਨ ਲਈ ਨੈਗੇਟਿਵ ਇਨਵੈਂਟਰੀ)। ਫਿਰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਇੱਕ ਬੈਕਗ੍ਰਾਊਂਡ ਚੈਕ ਰੱਖੋ ਜੋ ਮੁੜ-ਗਣਨਾ ਕਰਕੇ ਅਸਮਤੀ ਹੋਏ ਫਰਕਾਂ ਨੂੰ ਫਲੈਗ ਕਰੇ।

ਇੱਕ ਵਿਵਰਣਾਤਮਕ ਉਦਾਹਰਨ: ਦੋ ਯੂਜ਼ਰ ਇੱਕੋ ਕਾਰਟ 'ਚ ਇੱਕੋ ਸਮੇਂ ਆਈਟਮ ਜੋੜਦੇ ਹਨ। ਜੇ ਹਰ ਰਿਕਵੇਸਟ ਕਾਰਟ ਟੋਟਲ ਪੜ੍ਹਦਾ, ਆਪਣਾ ਆਈਟਮ ਪ੍ਰਾਈਸ ਜੋੜਦਾ, ਅਤੇ ਫਿਰ ਵਾਪਸ ਲਿਖਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਜੋੜ ਸੁੱਟ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਾਰਟ ਆਈਟਮ ਅਤੇ ਕਾਰਟ ਟੋਟਲ ਦੋਹਾਂ ਨੂੰ ਇੱਕ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਅਪਡੇਟ ਕਰੋ, ਤਾਂ ਭਾਰੀ ਪੈਰੱਲਲ ਕਲਿੱਕਾਂ ਹੇਠ ਵੀ ਟੋਟਲ ਸਹੀ ਰਹੇਗਾ।

ਪਹਿਲਾਂ ਡਾਟਾਬੇਸ ਕੰਸਟ੍ਰੇੰਟ ਨਾਲ ਟਕਰਾਅ ਰੋਕੋ

ਜੇ ਤੁਸੀਂ ਰੇਸ-ਕੰਡਿਸ਼ਨ ਘੱਟ ਕਰਨੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਡਾਟਾਬੇਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਐਪ ਕੋਡ ਰੀਟ੍ਰਾਈ, ਟਾਈਮਆਉਟ, ਜਾਂ ਦੋ ਵਾਰ ਚੱਲ ਸਕਦਾ ਹੈ। ਡਾਟਾਬੇਸ ਕੰਸਟ੍ਰੇੰਟ ਆਖਰੀ ਗੇਟ ਹੈ ਜੋ ਇਕੋ ਸਮੇਂ ਦੋ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਸਹੀ ਰੂਪ ਵਿੱਚ ਸੰਭਾਲਦਾ ਹੈ।

ਯੂਨੀਕ ਕੰਸਟ੍ਰੇੰਟ ਉਹ ਡੁਪਲਿਕੇਟ ਰੋਕਦਾ ਹੈ ਜੋ "ਕਦੇ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ" ਪਰ ਹੁੰਦਾ ਹੈ: ਇਮੇਲ ਪਤੇ, ਆਰਡਰ ਨੰਬਰ, ਇਨਵਾਇਸ ID, ਜਾਂ "ਪਰਤੀ ਯੂਜ਼ਰ ਇੱਕ ਇਕਟਿਵ ਸਬਸਕ੍ਰਿਪਸ਼ਨ" ਨਿਯਮ। ਜਦੋਂ ਦੋ ਸਾਈਨਅਪ ਇਕੱਠੇ ਆਉਂਦੇ ਹਨ, ਡਾਟਾਬੇਸ ਇੱਕ ਰੋਅ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਦੂਜੀ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ।

ਫਾਰੇਨ ਕੀਜ਼ ਟੁੱਟੇ ਹੋਏ ਹਵਾਲਿਆਂ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ। ਬਿਨਾਂ ਉਹਨਾਂ ਦੇ, ਇਕ ਰਿਕਵੇਸਟ ਮਾਪਾ ਮਾਪਾ ਪਿਤਾ ਰਿਕਾਰਡ ਹਟਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਦੂਜਾ ਚਾਈਲਡ ਰਿਕਾਰਡ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਓਰਫੈਨ ਰੋਅਜ਼ ਛੱਡ ਦਿੰਦਾ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸਾਫ਼ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

ਚੈੱਕ ਕੰਸਟ੍ਰੇੰਟਸ ਮੁੱਲਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੇਂਜ ਵਿੱਚ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਸਧਾਰਨ ਸਥਿਤੀ ਨਿਯਮ ਲਗਾਉਂਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ quantity >= 0, rating 1 ਤੋਂ 5 ਵਿਚਕਾਰ, ਜਾਂ status ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸੈਟ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ।

ਕੰਸਟ੍ਰੇੰਟ ਫੇਲਿਆਵਾਂ ਨੂੰ "ਸਰਵਰ ਐਰਰ" ਦੀ ਤਰ੍ਹਾਂ ਹੀ ਨਾ ਦਿਖਾਓ—ਉਹਨਾਂ ਨੂੰ ਉਮੀਦ ਕੀਤੀ ਤਰ੍ਹਾਂ ਸੋਚੋ। ਯੂਨੀਕ, ਫਾਰੇਨ ਕੀ, ਅਤੇ ਚੈੱਕ ਉਲੰਘਣਾ ਨੂੰ ਫੜੋ, ਇੱਕ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਵਾਪਸ ਕਰੋ ("ਉਹ ਇਮੇਲ ਪਹਿਲਾਂ ਤੋਂ ਵਰਤੀ ਜਾ ਚੁਕੀ ਹੈ") ਅਤੇ ਡੀਬੱਗ ਲਈ ਡੀਟੇਲ ਲੌਗ ਕਰੋ ਬਿਨਾਂ ਅੰਦਰੂਨੀ ਜਾਣਕਾਰੀ ਰਿਸਕ ਕੀਤੇ।

ਉਦਾਹਰਨ: ਦੋ ਲੋਕ ਲੈਗ ਦੇ ਦੌਰਾਨ "ਆਰਡਰ ਬਣਾਓ" ਦੋ ਵਾਰੀ ਕਲਿੱਕ ਕਰਦੇ ਹਨ। (user_id, cart_id) 'ਤੇ ਯੂਨੀਕ ਕੰਸਟ੍ਰੇੰਟ ਨਾਲ ਤੁਸੀਂ ਦੋ ਆਰਡਰ ਨਹੀਂ ਮਿਲਦੇ—ਤੁਹਾਨੂੰ ਇਕ ਆਰਡਰ ਅਤੇ ਇੱਕ ਸਾਫ਼, ਸਮਝਾਓ-ਯੋਗ ਰੱਦ ਮਿਲਦਾ ਹੈ।

ਜਦੋਂ ਇਕ ਬਦਲਾਅ ਨੂੰ ਜਿੱਤਣਾ ਲਾਜ਼ਮੀ ਹੋਵੇ ਤਾਂ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਅਤੇ ਲਾਕ ਵਰਤੋ

ਕੁਝ ਲਿਖਤਾਂ ਇਕ ਹੀ ਸਟੇਟਮੈਂਟ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਤੁਸੀਂ ਇੱਕ ਰੋਅ ਪੜ੍ਹਦੇ ਹੋ, ਇੱਕ ਨਿਯਮ ਚੈੱਕ ਕਰਦੇ ਹੋ, ਸਥਿਤੀ ਅਪਡੇਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਸ਼ਾਇਦ ਇੱਕ ਆਡਿਟ ਲੌਗ ਇੰਸਰਟ ਕਰਦੇ ਹੋ। ਜੇ ਦੋ ਰਿਕਵੇਸਟ ਇਕੱਠੇ ਇਹ ਕਰਦੇ ਹਨ, ਦੋਹਾਂ ਚੈੱਕ ਪਾਸ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਦੋਹਾਂ ਲਿਖ ਸਕਦੇ ਹਨ। ਇਹ ਕਲਾਸਿਕ ਫੇਲਿਅਰ ਪੈਟਰਨ ਹੈ।

ਮਲਟੀ-ਸਟੈਪ ਲਿਖਤ ਨੂੰ ਇਕ ਡਾਟਾਬੇਸ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਰੈਪ ਕਰੋ ਤਾਂ ਕਿ ਸਾਰੇ ਕਦਮ ਇਕੱਠੇ ਸਫਲ ਹੋਣ ਜਾਂ ਕੋਈ ਵੀ ਨਾ ਹੋਵੇ। ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਤੁਸੀਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕੋ ਸਮੇਂ ਕਿਹੜਾ ਬਦਲਾਅ ਹੋ ਸਕਦਾ ਹੈ।

ਜਦੋਂ ਕੇਵਲ ਇੱਕ ਏਕਟਰ ਇੱਕ ਰਿਕਾਰਡ ਦਾ ਸੰਪਾਦਨ ਕਰ ਸਕਦਾ ਹੈ, ਤਦ ਇੱਕ ਰੋਅ-ਸਤਰੀ ਲਾਕ ਵਰਤੋ। ਉਦਾਹਰਨ ਲਈ: ਆਰਡਰ ਰੋਅ ਨੂੰ ਲੌਕ ਕਰੋ, ਪੱਕਾ ਕਰੋ ਕਿ ਇਹ ਹਜੇ ਵੀ "pending" ਹੈ, ਫਿਰ ਇਸਨੂੰ "approved" ਕਰੋ ਅਤੇ ਆਡਿਟ ਏਂਟਰੀ ਲਿਖੋ। ਦੂਜੀ ਰਿਕਵੇਸਟ ਉਡੀਕ ਕਰੇਗੀ, ਫਿਰ ਸਥਿਤੀ ਨੂੰ ਮੁੜ-ਤਿਆਰ ਕਰੇਗੀ ਅਤੇ ਰੋਕ ਦੇਵੇਗੀ।

Optimistic vs pessimistic ਲਾਕਿੰਗ

ਕੋਸ਼ਿਸ਼ਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣੋ ਕਿ ਟਕਰਾਅ ਕਿੰਨਾ ਆਮ ਹੈ:

• Optimistic ਲਾਕਿੰਗ: ਇੱਕ ਵੇਰਜ਼ਨ ਨੰਬਰ (ਜਾਂ updated_at) ਜੋੜੋ ਅਤੇ ਅਪਡੇਟ ਸਿਰਫ਼ ਜਦੋਂ ਉਹ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ।
• Pessimistic ਲਾਕਿੰਗ: ਪਹਿਲਾਂ ਰੋਅ ਨੂੰ ਲੌਕ ਕਰੋ, ਫਿਰ ਅੰਦਰੋਨੀ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਪੜ੍ਹੋ ਅਤੇ ਅਪਡੇਟ ਕਰੋ।

ਲੌਕ ਸਮਾਂ ਛੋਟਾ ਰੱਖੋ। ਲੌਕ ਰੱਖਦੇ ਹੋਏ ਘੱਟੋ-ਘੱਟ ਕੰਮ ਕਰੋ: ਕੋਈ ਬਾਹਰੀ API ਕਾਲ ਨਾ ਕਰੋ, ਕੋਈ ਧੀਮਾ ਫਾਈਲ ਵਰਕ ਨਾ ਰੱਖੋ, ਕੋਈ ਵੱਡਾ ਲੂਪ ਨਾ ਚਲਾਓ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਟੂਲ 'ਚ ਫਲੋ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਸਿਰਫ਼ ਡਾਟਾਬੇਸ ਕਦਮਾਂ ਲਈ ਰੱਖੋ, ਫਿਰ ਬਾਕੀਆਂ ਕੰਮਾਂ ਨੂੰ ਕਮਿਟ ਤੋਂ ਬਾਅਦ ਕਰੋ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਇੱਕ ਲਿਖਤ ਫਲੋ ਨੂੰ ਅੰਤ-ਤੱਕ ਮਜ਼ਬੂਤ ਕਰੋ

ਇੱਕ ਐਸਾ ਫਲੋ ਚੁਣੋ ਜਿਸ ਤੋਂ ਟਕਰਾਅ ਹੋਣ 'ਤੇ ਪੈਸਾ ਜਾਂ ਭਰੋਸਾ ਖੋ ਸਕਦਾ ਹੈ। ਆਮ ਉਦਾਹਰਨ: ਆਰਡਰ ਬਣਾਉ, ਸਟੌਕ ਰਿਜ਼ਰਵ ਕਰੋ, ਫਿਰ ਆਰਡਰ ਸਥਿਤੀ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰੋ।

ਆਪਣੇ ਕੋਡ ਦੇ ਅਸਲ ਕਦਮਾਂ ਨੂੰ ਲਿਖੋ—ਸਪੈਸਿਫਿਕ ਕੀ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਕੀ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ "ਸਫਲਤਾ" ਦਾ ਮਤਲਬ ਕੀ ਹੈ। ਟਕਰਾਅ ਪੜ੍ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਲਿਖਣ ਦਰਮਿਆਨ ਛੱਡੇ ਥਾਂਵਾਂ ਵਿੱਚ ਹੋਂਦ ਵਿੱਚ ਹੁੰਦੇ ਹਨ।

ਜ਼ਿਆਦਾਤਰ ਸਟੈਕ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲਾ ਇੱਕ ਮਜ਼ਬੂਤ ਰਾਹ:

• ਉਹ ਬੁਰੇ ਨਤੀਜੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਤੁਹਾਨੂੰ ਰੋਕਣੇ ਹਨ (ਉਦਾਹਰਨ: ਸਟੋਕ ਨੈਗੇਟਿਵ ਹੋਣਾ, ਜਾਂ ਇੱਕੋ ਆਰਡਰ ਲਾਈਨ ਲਈ ਦੋ ਰਿਜ਼ਰਵੇਸ਼ਨ)।
• ਇੱਕ ਡਾਟਾਬੇਸ ਨਿਯਮ ਜੋ ਉਸ ਨਤੀਜੇ ਨੂੰ ਅਸੰਭਵ ਬਣਾਏ ਜੋੜੋ (ਉਦਾਹਰਨ: CHECK constraint ਜੋ stock < 0 ਰੋਕਦਾ ਹੈ, ਅਤੇ reservations ਲਈ (order_id, sku) 'ਤੇ UNIQUE constraint)।
• ਸਾਰੇ ਕਦਮਾਂ ਨੂੰ ਇੱਕ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਉਹ ਰੋਅਜ਼ ਲੌਕ ਕਰੋ ਜੋ ਨਤੀਜਾ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ: stock ਰੋਅ ਨੂੰ subtract ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੌਕ ਕਰੋ)।
• ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਅਪਡੇਟ ਨੂੰ ਇੱਕ ਸਟੇਟਮੈਂਟ ਵਿੱਚ ਕਰੋ (ਉਦਾਹਰਨ: "update stock where stock >= qty" ਤਾਂ ਕਿ ਇਹ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋ ਜਾਏ)।
• ਟਕਰਾਅਾਂ ਨੂੰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਲ ਕਰੋ: ਕੁਝ ਵਾਰੀ ਰੀਟ੍ਰਾਈ ਕਰੋ, ਜਾਂ ਇੱਕ ਸਪਸ਼ਟ "Out of stock, please refresh" ਸੁਨੇਹਾ ਵਾਪਸ ਕਰੋ।

ਇਕ ਟੈਸਟ ਜੋ ਫਿਕਸ ਨੂੰ ਸਾਬਤ ਕਰੇ: ਇਕੋ ਸਮੇਂ ਦੋ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਇੱਕੋ ਉਤਪਾਦ ਅਤੇ ਮਾਤਰਾ 'ਤੇ ਚਲਾਓ। ਦਾਅਵਾ ਕਰੋ ਕਿ ਸਿਰਫ਼ ਇਕ ਆਰਡਰ ਪੱਕਾ ਹੋਵੇ ਅਤੇ ਦੂਜਾ ਨਿਯੰਤਰਿਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋਵੇ (ਕੋਈ ਨੈਗੇਟਿਵ ਸਟਾਕ, ਕੋਈ ਡੁਪਲਿਕੇਟ ਰਿਜ਼ਰਵੇਸ਼ਨ ਰੋਅਜ਼ ਨਾਂ ਹੋਣ)।

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਐਪ ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ (Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ ਦੇ ਨਾਲ), ਇਹ ਚੈਕਲਿਸਟ ਫਲੋਜ਼ ਤੇ ਲਾਗੂ ਕਰਨ ਯੋਗ ਹੈ।

ਉਹ ਆਮ ਗਲਤੀਆਂ ਜੋ ਰੇਸ-ਕੰਡਿਸ਼ਨ ਜਿੰਦ ਬਣਾਈ ਰੱਖਦੀਆਂ ਹਨ

ਇੱਕ ਸਭ ਤੋਂ ਵੱਡਾ ਕਾਰਨ UI 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਹੈ। ਡਿਸੇਬਲ ਬਟਨ ਅਤੇ ਕਲਾਇੰਟ-ਸਾਈਡ ਚੈਕਸ ਮਦਦਗਾਰ ਹਨ, ਪਰ ਉਪਭੋਗਤਾ ਡਬਲ-ਕਲਿੱਕ ਕਰ ਸਕਦੇ ਹਨ, ਰੀਫ੍ਰੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ, ਦੋ ਟੈਬ ਖੋਲ੍ਹ ਸਕਦੇ ਹਨ, ਜਾਂ ਕਿਸੇ ਰਿਕਵੈਸਟ ਨੂੰ ਫਲੈਕੀ ਕਨੈਕਸ਼ਨ ਤੋਂ ਦੁਹਰਾਵਾ ਸਕਦੇ ਹਨ। ਜੇ ਸਰਵਰ ਆਇਡੈਂਟੋਟੈਂਟ ਨਹੀਂ ਹੈ, ਤਾ ਡੁਪਲਿਕੇਟ ਆਉਂਦੇ ਰਹਿੰਦੇ ਹਨ।

ਹੋਰ ਇੱਕ ਖ਼ਾਮੋਸ਼ੀ ਭਰਪੂਰ ਬੱਗ: ਤੁਸੀਂ ਡਾਟਾਬੇਸ ਐਰਰ (ਜਿਵੇਂ ਯੂਨੀਕ ਕੰਸਟ੍ਰੇੰਟ) ਫੜਦੇ ਹੋ ਪਰ ਫਿਰ ਵੀ ਵਰਕਫਲੋ ਜਾਰੀ ਰੱਖਦੇ ਹੋ। ਅਕਸਰ ਇਹ "ਬਣਾਉ ਫੇਲ ਹੋ ਗਿਆ, ਪਰ ਅਸੀਂ ਫਿਰ ਵੀ ਈਮੇਲ ਭੇਜ ਦਿੱਤੀ" ਜਾਂ "ਭੁਗਤਾਨ ਫੇਲ ਹੋ ਗਿਆ, ਪਰ ਅਸੀਂ ਆਰਡਰ ਨੂੰ ਪੇਡ ਮਾਰਕ ਕਰ ਦਿੱਤਾ" ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵਾਰੀ ਸਾਈਡ-ਐਫੇਕਟ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਵਾਪਸ ਪറ്റਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

ਲੰਬੇ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵੀ ਇੱਕ ਜਾਲ ਹਨ। ਜੇ ਤੁਸੀਂ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਖੁੱਲ੍ਹਾ ਰੱਖ ਕੇ ਈਮੇਲ, ਭੁਗਤਾਨ, ਜਾਂ ਤੀਜੀ-ਪੱਖੀ API ਕਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਲੌਕ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ ਲਈ ਰੱਖ ਲੈਂਦੇ ਹੋ। ਇਹ ਉਡੀਕ, ਟਾਈਮਆਉਟ, ਅਤੇ ਰਿਕਵੇਸਟਾਂ ਦੇ ਇਕ-ਦੂਜੇ ਨੂੰ ਰੋਕਣ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦਾ ਹੈ।

ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਅਤੇ ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਕ-ਸੋੱਸ ਆਫ਼-ਟ੍ਰੂਥ ਦੇ ਬਿਨਾਂ ਮਿਲਾਉਣਾ ਛਿੜ-ਮਗੜ ਰਾਜ ਬਣਾਉਂਦਾ ਹੈ। ਜੌਬ ਰੀਟ੍ਰਾਈ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਰੋਅ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਯੂਜ਼ਰ ਉਸਨੂੰ ਸੰਪਾਦਨ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹੁਣ ਦੋਹਾਂ ਸੋਚਦੇ ਹਨ ਕਿ ਉਹ ਆਖਰੀ ਲਿਖਨਹਾਰ ਹਨ।

ਕੁਝ "ਫਿਕਸ" ਜੋ ਸਚਮੁਚ ਫਿਕਸ ਨਹੀਂ ਕਰਦੇ:

• ਸਿਰਫ਼ UI-ਪੱਖੀ ਡਬਲ-ਸਬਮਿਟ ਰੋਕਥਾਮ
• ਇੱਕ ਐਰਰ ਨੂੰ ਚੁੱਪ ਕਰਕੇ ਅੱਗੇ ਵਧਣਾ
• ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਧੀਮੇ ਨੈਟਵਰਕ ਕਾਲਾਂ ਕਰਨਾ
• ਜੌਬਾਂ ਅਤੇ ਯੂਜ਼ਰ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਇਕੋ ਸਥਿਤੀ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਅਪਡੇਟ ਕਰਨ ਦੇਣਾ
• ਪੜ੍ਹੋ-ਮਰੋ-ਲਿਖੋ ਨਾਲ ਕਾਊਂਟਰ ਅਪਡੇਟ ਕਰਨਾ

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਕੇ ਬਿਲਡ ਕਰ ਰਹੇ ਹੋ, ਇਹੋ ਹੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ: ਸਰਵਰ-ਸਾਈਡ ਕੰਸਟ੍ਰੇੰਟ ਤੇ ਸਪੱਠ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਸੀਮਾਵਾਂ ਮੰਗੋ, ਸਿਰਫ਼ ਸੋਹਣੇ UI ਗਾਰਡ ਨਹੀਂ।

ਸ਼ਿੱਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕ

ਰੇਸ-ਕੰਡਿਸ਼ਨ ਅਕਸਰ ਸਿਰਫ਼ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਹੇਠ ਹੀ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ। ਇੱਕ ਪ੍ਰੀ-ਸ਼ਿਪ ਪਾਸ ਜ਼ਿਆਦਾਤਰ ਆਮ ਟਕਰਾਅ-ਬਿੰਦੂਆਂ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਕੈਚ ਕਰ ਸਕਦਾ ਹੈ।

ਡਾਟਾਬੇਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਕੁਝ ਯੂਨੀਕ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ (ਈਮੇਲ, ਇਨਵਾਇਸ ਨੰਬਰ, ਪ੍ਰਤੀ-ਯੂਜ਼ਰ ਇਕ ਐਕਟਿਵ ਸਬਸਕ੍ਰਿਪਸ਼ਨ), ਤਾਂ ਉਹ ਇੱਕ ਅਸਲ ਯੂਨੀਕ ਕੰਸਟ੍ਰੇੰਟ ਹੋਵੇ, ਨਾ ਕਿ ਐਪ-ਲੇਵਲ "ਸਾਨੂੰ ਪਹਿਲਾਂ ਚੈੱਕ ਕਰਨ ਦੀ ਆਦਤ ਹੈ"। ਫਿਰ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡਾ ਕੋਡ ਕੰਸਟ੍ਰੇੰਟ ਦੇ ਕਦੇ-ਕਦੇ ਫੇਲ ਹੋਣ ਦੀ ਉਮੀਦ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ, ਸੁਰੱਖਿਅਤ ਜਵਾਬ ਵਾਪਸ ਕਰਦਾ ਹੈ।

ਅਗਲਾ, ਸਥਿਤੀ ਦੇਖੋ। ਕੋਈ ਵੀ ਸਥਿਤੀ ਬਦਲਾਅ (Draft -> Submitted -> Approved) ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਟਰਾਂਜ਼ੀਸ਼ਨ ਦੀ ਇੱਕ ਸੂਚੀ ਦੇ ਖ਼ਿਲਾਫ਼ ਵੈਧਤਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਦੋ ਰਿਕਵੇਸਟ ਇੱਕੋ ਰਿਕਾਰਡ ਨੂੰ ਹਿਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਤਾਂ ਦੂਜੀ ਨੂੰ ਰੱਦ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਇਹ ਨੋ-ਓਪ ਬਣ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਇਕ ਵਿਚਕਾਰਲੀ ਸਥਿਤੀ ਬਣ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰੀ-ਰਿਲੀਜ਼ ਚੈਕਲਿਸਟ:

• ਹਰ "ਮੁਸਤ-ਯੂਨੀਕ" ਨਿਯਮ ਲਈ ਯੂਨੀਕ ਕੰਸਟ੍ਰੇੰਟ ਮੌਜੂਦ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਸ਼ਾਮਲ ਕਾਮਪੋਜ਼ਿਟ ਵੀ।
• ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹਰ ਲਿਖਤ ਐਂਡਪਾਇੰਟ ਰੀਟ੍ਰਾਈ ਲਈ ਸੇਫ ਹੈ (ਆਇਡੈਂਟੋਟੈਂਸੀ ਕੀ, ਰਿਕਵੇਸਟ ID, ਜਾਂ ਕੁਦਰਤੀ ਆਇਡੈਂਟੋਟੈਂਸੀ)।
• ਮਲਟੀ-ਸਟੈਪ ਲਿਖਤਾਂ ਨੂੰ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਰੱਖੋ, ਖਾਸਕਰ ਜਦੋਂ ਤੁਸੀਂ ਪੜ੍ਹਦੇ ਹੋ ਅਤੇ ਫਿਰ ਪੜ੍ਹੇ ਆਧਾਰ 'ਤੇ ਲਿਖਦੇ ਹੋ।
• ਕੇਵਲ ਜਿੱਥੇ ਇੱਕ ਬਦਲਾਅ ਜਿੱਤਣਾ ਲਾਜ਼ਮੀ ਹੋ (ਜਿਵੇਂ ਇੱਕ ਆਰਡਰ ਲਈ ਇੱਕ_APPROVAL), ਉੱਥੇ ਲਾਕ ਵਰਤੋ।
• ਕਨਫਲਿਕਟ ਸਿਗਨਲਾਂ (ਡੁਪਲਿਕੇਟ ਕੀ ਐਰਰ, serialization ਫੇਲਯਰ, ਲੌਕ ਟਾਈਮਆਉਟ) ਨੂੰ ਲੌਗ ਅਤੇ ਅਲਰਟ ਕਰੋ।

ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਫਲੋਜ਼ ਬਣਾਉਂਦੇ ਹੋ, ਇਨ੍ਹਾਂ ਨੂੰ acceptance criteria ਵਾਂਗ ਰੱਖੋ: ਜਨਰੇਟ ਕੀਤੀ ਐਪ ਨੂੰ ਰੀਪੀਟ ਅਤੇ ਕੁਨਕਰਨਸੀ ਹੇਠ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਫੇਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਹੈਪੀ ਪਾਥ ਪਾਸ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਉਦਾਹਰਨ ਦ੍ਰਿਸ਼: ਡਬਲ ਅਪ੍ਰੂਵਲ ਰੋਕਣਾ

ਦੋ ਸਟਾਫ ਮੈਂਬਰ ਇੱਕੋ ਪਚੇ ਖਰੀਦ ਅਰਜ਼ੀ ਖੋਲ੍ਹਦੇ ਹਨ। ਦੋਹਾਂ ਕੁਝ ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ Approve 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹਨ। ਦੋਹਾਂ ਰਿਕਵੇਸਟ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ।

ਗਲਤ ਹੋਣ ਵਾਲੀ ਚੀਜ਼ ਗੁੰਝਲਦਾਰ ਹੋ ਸਕਦੀ ਹੈ: ਅਰਜ਼ੀ ਦੁਬਾਰਾ "approved" ਹੋ ਜਾਂਦੀ ਹੈ, ਦੋ ਸੂਚਨਾ-ਸಂದੇਸ਼ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਮਨਜ਼ੂਰ ਨਾਲ ਜੁੜੇ ਟੋਟਲ (ਬਜਟ ਵਰਤੀ, ਦੈਨਿਕ ਮਨਜ਼ੂਰੀਆਂ ਦੀ ਗਿਣਤੀ) 2 ਨਾਲ ਜੰਪ ਕਰ ਸਕਦੇ ਹਨ। ਦੋਹਾਂ ਅੱਪਡੇਟ ਆਪਣੇ ਆਪ ਵਿੱਚ ਵੈਧ ਹਨ, ਪਰ ਉਹ ਟਕਰਾਅ ਕਰਦੇ ਹਨ।

ਇੱਕ ਫਿਕਸ ਯੋਜਨਾ ਜੋ PostgreSQL-ਸਟਾਈਲ ਡਾਟਾਬੇਸ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ:

1) ਡਬਲ ਅਪ੍ਰੂਵਲ ਨੂੰ ਡਾਟਾਬੇਸ ਵਿੱਚ ਅਸੰਭਵ ਬਣਾਓ

ਆਰਜ਼ੀਆਂ ਲਈ ਅਲੱਗ ਸਾਰਣੀ ਵਿੱਚ approvals ਸਟੋਰ ਕਰੋ ਅਤੇ request_id 'ਤੇ UNIQUE constraint ਲਗਾਓ। ਹੁਣ ਦੂਜੀ ਇੰਸਰਟ ਫੇਲ ਹੋ ਜਾਵੇਗੀ ਭਾਵੇਂ ਕਿ ਐਪ ਕੋਡ ਵਿੱਚ ਬੱਗ ਹੋਵੇ।

2) ਸਥਿਤੀ ਬਦਲਾਅ ਨੂੰ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਰੱਖੋ

Approval ਕਰਦਿਆਂ, ਸਾਰੀ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਇਹ ਕਰੋ:

• request ਰੋਅ ਨੂੰ ਲੌਕ ਕਰੋ (ਜਾਂ ਉਸਨੂੰ ਇਸ ਸ਼ਰਤ ਨਾਲ ਅਪਡੇਟ ਕਰੋ WHERE status = 'pending')।
• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਹਜੇ ਵੀ pending ਹੈ।
• approval ਰਿਕਾਰਡ ਲਿਖੋ।
• request ਦੀ ਸਥਿਤੀ approved 'ਤੇ ਅਪਡੇਟ ਕਰੋ।

ਜੇ ਦੂਜਾ ਸਟਾਫ ਮੈਂਬਰ ਦੇਰ ਨਾਲ ਆਵੇ, ਤਾਂ ਉਹ ਜਾਂ ਤਾਂ 0 ਰੋਅਜ਼ ਅਪਡੇਟ ਹੋਏ ਵੇਖੇਗਾ ਜਾਂ ਯੂਨੀਕ-ਕੰਸਟ੍ਰੇੰਟ ਐਰਰ ਆਵੇਗਾ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਕੇਵਲ ਇਕ ਬਦਲਾਅ ਜਿੱਤਦਾ ਹੈ।

3) UI ਨੂੰ ਸਪਸ਼ਟ ਫੀਡਬੈਕ ਦਿਓ

ਫਿਕਸ ਦੇ ਬਾਅਦ, ਪਹਿਲਾ ਸਟਾਫ ਮੈਂਬਰ Approved ਵੇਖੇਗਾ ਅਤੇ ਆਮ ਪੁਸ਼ਟੀਗਤੀ ਮਿਲੇਗੀ। ਦੂਜਾ ਸਟਾਫ ਮੈਂਬਰ ਇੱਕ ਦੋਸਤਾਨਾ ਸੁਨੇਹਾ ਵੇਖੇਗਾ: "ਇਹ ਰਿਕਵੇਸਟ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਹੋਰ ਵੱਲੋਂ ਮਨਜ਼ੂਰ ਕੀਤੀ ਜਾ ਚੁਕੀ ਹੈ। ਤाज़ਾ ਸਥਿਤੀ ਦੇਖਣ ਲਈ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ।" ਕੋਈ ਘੁੰਮਣਾ ਨਹੀਂ, ਕੋਈ ਡੁਪਲਿਕੇਟ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨਹੀਂ, ਕੋਈ ਚੁੱਪ-ਚਾਪ ਫੇਲ ਨਹੀਂ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ (Go ਬੈਕਏਂਡ ਨਾਲ PostgreSQL) 'ਤੇ CRUD ਫਲੋ ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਚੈੱਕApprove action 'ਚ ਇੱਕ ਵਾਰੀ ਬੇਕ ਕਰੋ ਅਤੇ ਇਸ ਪੈਟਰਨ ਨੂੰ ਹੋਰ "ਕੇਵਲ ਇੱਕ ਜਿੱਤ" ਕਾਰਵਾਈਆਂ ਲਈ ਦੁਹਰਾਓ।

ਅਗਲੇ ਕਦਮ: ਰੇਸ ਫਿਕਸਾਂ ਨੂੰ ਆਪਣੇ ਬਿਲਡ ਰੁਟੀਨ ਦਾ ਹਿੱਸਾ ਬਣਾਓ

ਰੇਸ-ਕੰਡਿਸ਼ਨ ਸਭ ਤੋਂ ਆਸਾਨ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਦੁਹਰਾਅਯੋਗ ਰੁਟੀਨ ਵਜੋਂ ਲੈਂਦੇ ਹੋ, ਨਾ ਕਿ ਇੱਕ ਵਾਰੀ ਦਾ ਬੱਗ-ਸ਼ੋਧ। ਉਹਨਾਂ ਕੁਝ ਲਿਖਤ-ਰਸਤੇਆਂ ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮੁੱਲ ਖੋ ਸਕਦੇ ਹਨ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਨੂੰ ਬੋਰਿੰਗ ਤਰੀਕੇ ਨਾਲ ਠੀਕ ਕਰੋ।

ਆਰੰਭ ਕਰੋ ਆਪਣੀਆਂ ਮੁੱਖ ਟਕਰਾਅ-ਥਾਂਵਾਂ ਨੂੰ ਨਾਮ ਦੇ ਕੇ। ਬਹੁਤ CRUD ਐਪਾਂ ਵਿੱਚ ਇਹ ਉਹੀ ਤਿੰਨ ਹੁੰਦੀਆਂ ਹਨ: ਕਾਊਂਟਰ (ਲਾਈਕ, ਇਨਵੈਂਟਰੀ, ਬੈਲੇਂਸ), ਸਥਿਤੀ ਬਦਲਾਅ (Draft -> Submitted -> Approved), ਅਤੇ ਡਬਲ-ਸਬਮਿਟ (ਡਬਲ-ਕਲਿੱਕ, ਰੀਟ੍ਰਾਈਜ਼, ਧੀਮਾ ਨੈਟਵਰਕ)।

ਇਕ ਰੁਟੀਨ ਜੋ ਕੰਮ ਕਰਦੀ ਹੈ:

• ਹਰ ਫਲੋ ਲਈ ਇੱਕ ਸੱਚਾ ਨਿਯਮ ਲਿਖੋ (ਉਦਾਹਰਨ: ਇੱਕ ਆਰਡਰ ਇਕ ਵਾਰੀ ਹੀ ਮਨਜ਼ੂਰ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੇਵਲ pending ਤੋਂ)।
• ਪਹਿਲਾਂ ਡਾਟਾਬੇਸ ਕੰਸਟ੍ਰੇੰਟ ਜੋੜੋ (ਯੂਨੀਕ ਕੀ, ਫਾਰੇਨ ਕੀ, ਚੈੱਕ) ਤਾਂ ਕਿ ਡਾਟਾਬੇਸ ਅਸੰਭਵ ਸਥਿਤੀਆਂ ਨੂੰ ਰੱਦ ਕਰ ਦੇਵੇ।
• ਜਿੱਥੇ ਇੱਕ ਬਦਲਾਅ ਜਿੱਤਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਓਥੇ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਲਾਕ ਜੋੜੋ।
• ਹਰ ਗੰਭੀਰ ਵਰਕਫਲੋ ਲਈ ਇੱਕ ਛੋਟਾ ਕੰਕਰਨਸੀ ਟੈਸਟ ਬਣਾਓ ਜੋ ਤੁਹਾਡੇ ਡਰ ਨੂੰ ਲਕੜੀ ਕਰੇ (ਦੋ approvals, ਦੋ increments, ਦੋ ਫਾਰਮ ਸਬਮਿਟ)।
• ਐਰਰ ਹੈਂਡਲਿੰਗ ਰਿਵਿਊ ਕਰੋ ਤਾਂ ਕਿ UI ਡਾਟਾਬੇਸ ਦੁਆਰਾ ਰੱਦ ਕੀਤੀ ਗਈ ਲਿਖਤ ਨੂੰ ਸਪਸ਼ਟ ਸੁਨੇਹੇ ਦੇ ਕੇ ਦਰਸਾਏ।

ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, Planning Mode ਵਿੱਚ ਹਰ ਲਿਖਤ ਫਲੋ ਨੂੰ ਕਦਮਾਂ ਅਤੇ ਨਿਯਮਾਂ ਵਜੋਂ ਨਕਸ਼ਾ ਬਣਾਓ ਪਹਿਲਾਂ, ਫਿਰ Go + PostgreSQL ਲਈ ਕੋਡ ਜਨਰੇਟ ਕਰੋ। ਨਵੀਂ ਕੰਸਟ੍ਰੇੰਟ ਜਾਂ ਲਾਕ ਵਿਹਾਰ ਤਿਆਰ ਕਰਦਿਆਂ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਤੇਜ਼ ਵਾਪਸੀ ਲਈ ਸਹਾਇਕ ਹੋ ਸਕਦੇ ਹਨ।

ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਆਦਤ ਬਣ ਜਾਂਦੀ ਹੈ: ਹਰ ਨਵੀਂ ਲਿਖਤ ਫੀਚਰ ਲਈ ਇਕ ਕੰਸਟ੍ਰੇੰਟ, ਇੱਕ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਯੋਜਨਾ, ਅਤੇ ਇੱਕ ਕੁਨਕਰਨਸੀ ਟੈਸਟ। ਇਸ ਤਰ੍ਹਾਂ CRUD ਐਪਾਂ ਵਿੱਚ ਰੇਸ-ਕੰਡਿਸ਼ਨ ਹੈਰਾਨੀ ਦਾ ਵਿ਷ਾ ਨਹੀਂ ਰਹਿੰਦੇ।