ਸਪਰਿੰਗ ਬੂਟ ਗਲਤੀ ਨੂੰ ਠੀਕ ਕਰਨਾ: ਅੱਖਰ ਵੱਖੋ-ਵੱਖਰੇ ਅਤੇ ਛੋਟੀਆਂ ਕਿਸਮਾਂ ਦਾ ਕੋਈ ਆਪਰੇਟਰ ਨਹੀਂ ਹੈ

ਸਪਰਿੰਗ ਬੂਟ SQL ਸਵਾਲਾਂ ਦੇ ਨਾਲ ਆਮ ਨੁਕਸਾਨ: PostgreSQL ਵਿੱਚ ਕਿਸਮ ਦੇ ਮੇਲ ਖਾਂਦੇ ਹਨ

ਡਿਵੈਲਪਰ ਹੋਣ ਦੇ ਨਾਤੇ, ਅਸੀਂ ਸਾਰੇ ਗੁਪਤ ਗਲਤੀ ਸੁਨੇਹਿਆਂ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ ਹੈ ਜੋ ਕਿ ਕਿਤੇ ਵੀ ਨਹੀਂ ਆਉਂਦੇ ਜਾਪਦੇ ਹਨ। ਇੱਕ ਮਿੰਟ, ਸਾਡਾ ਸਪਰਿੰਗ ਬੂਟ ਐਪਲੀਕੇਸ਼ਨ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਚੱਲ ਰਿਹਾ ਹੈ; ਅਗਲਾ, ਅਸੀਂ ਅਸੰਗਤ ਡੇਟਾ ਕਿਸਮਾਂ ਬਾਰੇ ਇੱਕ ਤਰੁੱਟੀ ਨੂੰ ਵੇਖ ਰਹੇ ਹਾਂ। 😅 ਇਹ ਨਿਰਾਸ਼ਾਜਨਕ ਅਤੇ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲਾ ਦੋਵੇਂ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਗੁੰਝਲਦਾਰ ਪੁੱਛਗਿੱਛ ਸੈੱਟਅੱਪਾਂ ਨਾਲ ਨਜਿੱਠਣ ਵੇਲੇ।

ਹਾਲ ਹੀ ਵਿੱਚ, ਮੈਂ ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਇੱਕ PostgreSQL ਗਲਤੀ ਵਿੱਚ ਭੱਜਿਆ: "ਓਪਰੇਟਰ ਮੌਜੂਦ ਨਹੀਂ ਹੈ: ਅੱਖਰ ਭਿੰਨ = ਸਮਾਲਇੰਟ।" ਏ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਇਹ ਸੁਨੇਹਾ ਦਿਖਾਈ ਦਿੱਤਾ enums ਦਾ ਸੈੱਟ ਇੱਕ SQL ਪੁੱਛਗਿੱਛ ਦੇ IN ਧਾਰਾ ਵਿੱਚ. ਐਨਮ ਕਿਸਮ ਅਤੇ ਡੇਟਾਬੇਸ ਕਾਲਮ ਕਿਸਮ ਦੇ ਵਿਚਕਾਰ ਮੇਲ ਨਾ ਹੋਣ ਨੇ ਸਿੱਧੇ ਕੋਡ ਦੀ ਤਰ੍ਹਾਂ ਜਾਪਦੇ ਵਿੱਚ ਇੱਕ ਅਚਾਨਕ ਹਿਚਕੀ ਪੈਦਾ ਕੀਤੀ।

ਹਾਲਾਂਕਿ ਇਹ ਡੇਟਾਬੇਸ ਕੁਇਰਕਸ ਜਾਂ ਸਪਰਿੰਗ ਬੂਟ ਨੂੰ ਦੋਸ਼ੀ ਠਹਿਰਾਉਣ ਲਈ ਪਰਤੱਖ ਰਿਹਾ ਹੈ, ਅਸਲ ਮੁੱਦਾ ਅਕਸਰ ਇਸ ਗੱਲ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਐਨਮ ਅਤੇ ਡੇਟਾਬੇਸ ਕਿਸਮਾਂ ਨੂੰ ਮੈਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। Java enums, ਜਦੋਂ ਡੇਟਾਬੇਸ ਨਾਲ ਮੈਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ PostgreSQL ਨਾਲ, ਖਾਸ ਹੈਂਡਲਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹਨਾਂ ਵੇਰਵਿਆਂ ਨੂੰ ਸਮਝਣਾ ਸਮੇਂ ਦੀ ਬਚਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ enums ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਭਵਿੱਖ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।

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

PostgreSQL ਨਾਲ ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਡਾਟਾ ਕਿਸਮ ਦੇ ਮੇਲ ਖਾਂਦਾ ਹੱਲ ਕਰਨਾ

ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਬਸੰਤ ਬੂਟ ਅਤੇ PostgreSQL, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਅਕਸਰ ਕਿਸਮ ਦੇ ਬੇਮੇਲ ਮੁੱਦਿਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ enums ਦੇ ਨਾਲ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਗਲਤੀ "ਓਪਰੇਟਰ ਮੌਜੂਦ ਨਹੀਂ ਹੈ: ਅੱਖਰ ਭਿੰਨਤਾ = ਸਮਾਲਇੰਟ" ਵਾਪਰਦਾ ਹੈ ਕਿਉਂਕਿ PostgreSQL ਇੱਕ Java enum ਨੂੰ ਮੂਲ ਸਵਾਲਾਂ ਵਿੱਚ SQL ਕਿਸਮ ਦੇ ਤੌਰ ਤੇ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਥੇ, SystemAccounts ਇਕਾਈ ਵਿੱਚ AccountType enum ਦੁਆਰਾ ਪ੍ਰਸਤੁਤ ਕੀਤਾ ਗਿਆ ਉਪਭੋਗਤਾ ਕੋਡ ਖੇਤਰ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਜੋ ਜਾਵਾ ਵਿੱਚ "ਪਰਸਨਲ" ਜਾਂ "ਕਾਰਪੋਰੇਟ" ਵਰਗੇ ਮੁੱਲਾਂ ਨੂੰ ਮੈਪ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜਦੋਂ enums ਦੇ ਇੱਕ ਸਮੂਹ ਦੇ ਨਾਲ ਇੱਕ ਮੂਲ SQL ਪੁੱਛਗਿੱਛ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ PostgreSQL ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ enum ਕਿਸਮਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਨਤੀਜੇ ਵਜੋਂ ਇਹ ਗਲਤੀ ਹੁੰਦੀ ਹੈ। ਇਸ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ, enum ਨੂੰ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਪਾਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਤਰ ਵਿੱਚ ਬਦਲਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। 🎯

ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਹੱਲ ਵਿੱਚ, ਅਸੀਂ @Enumerated(EnumType.STRING) ਐਨੋਟੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ SystemAccounts ਵਿੱਚ enum ਮੈਪਿੰਗ ਨੂੰ ਐਡਜਸਟ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ। ਇਹ JPA ਨੂੰ ਸੰਖਿਆਤਮਕ ਆਰਡੀਨਲ ਦੀ ਬਜਾਏ ਹਰੇਕ ਖਾਤਾ ਟਾਈਪ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਸਤਰ ਵਜੋਂ ਸਟੋਰ ਕਰਨ ਲਈ ਨਿਰਦੇਸ਼ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਤਬਦੀਲੀ ਹੈ, ਪਰ ਇਹ ਸੰਖਿਆਤਮਕ ਮੁੱਲਾਂ ਤੋਂ ਬਚ ਕੇ ਭਵਿੱਖ ਦੇ ਡੇਟਾ ਹੈਂਡਲਿੰਗ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਡੇਟਾਬੇਸ ਵਿੱਚ ਡੀਬੱਗਿੰਗ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾ ਦੇਵੇਗਾ। ਸਾਡੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ, ਅਸੀਂ ਫਿਰ SQL ਤਰਕ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨ ਲਈ ਇੱਕ ਕਸਟਮ @Query ਐਨੋਟੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ। ਹਾਲਾਂਕਿ, ਕਿਉਂਕਿ PostgreSQL ਨੂੰ ਅਜੇ ਵੀ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਸਟ੍ਰਿੰਗਾਂ ਦੇ ਰੂਪ ਵਿੱਚ enums ਦੀ ਲੋੜ ਹੈ, ਸਾਨੂੰ ਉਹਨਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ AccountType ਮੁੱਲਾਂ ਨੂੰ ਇੱਕ ਸਟ੍ਰਿੰਗ ਫਾਰਮੈਟ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

CriteriaBuilder API ਇਸ ਮੁੱਦੇ ਦਾ ਇੱਕ ਗਤੀਸ਼ੀਲ ਹੱਲ ਪੇਸ਼ ਕਰਦਾ ਹੈ। CriteriaBuilder ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ Java ਵਿੱਚ ਪ੍ਰੋਗ੍ਰਾਮਿਕ ਤੌਰ 'ਤੇ ਸਵਾਲਾਂ ਨੂੰ ਬਣਾ ਕੇ ਮੂਲ SQL ਤੋਂ ਬਚ ਸਕਦੇ ਹਾਂ। ਇਹ ਪਹੁੰਚ ਸਾਨੂੰ SQL ਨੂੰ ਹੱਥ ਨਾਲ ਲਿਖੇ ਬਿਨਾਂ ਐਨਮ ਫਿਲਟਰ ਜੋੜਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ SQL ਗਲਤੀਆਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਸਾਂਭ-ਸੰਭਾਲ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਸਾਡੀ ਸਕ੍ਰਿਪਟ ਵਿੱਚ, ਅਸੀਂ ਸੈੱਟ ਵਿੱਚ ਹਰੇਕ AccountType ਨਾਲ ਮੇਲ ਕਰਨ ਲਈ cb.equal() ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਹਰੇਕ enum ਦੇ ਸਟ੍ਰਿੰਗ ਵੈਲਯੂ ਦੇ ਆਧਾਰ 'ਤੇ ਪ੍ਰੀਡੀਕੇਟ ਸ਼ਰਤਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਬਣਾਉਂਦੇ ਹਾਂ। ਫਿਰ, cb.or() ਇਹਨਾਂ ਪੂਰਵ-ਅਨੁਮਾਨਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ, ਇੱਕੋ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਕਈ ਮੁੱਲਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਹ ਲਚਕਦਾਰ ਸੈਟਅਪ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਐਨਮ-ਟੂ-ਸਟ੍ਰਿੰਗ ਪਰਿਵਰਤਨ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, PostgreSQL ਨਾਲ ਅਨੁਕੂਲਤਾ ਮੁੱਦਿਆਂ ਨੂੰ ਘੱਟ ਕਰਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਹੱਲ ਅਨੁਕੂਲਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਇੱਕ ਯੂਨਿਟ ਟੈਸਟ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। JUnit ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਾਂ ਕਿ ਹਰੇਕ AccountType ਸਾਡੀ ਪੁੱਛਗਿੱਛ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰਕੋਡ ਖੇਤਰ "ਪਰਸਨਲ" ਜਾਂ "ਕਾਰਪੋਰੇਟ" ਮੁੱਲਾਂ ਨੂੰ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਤਰੁੱਟੀ ਦੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਟੈਸਟ ਵਿਧੀ ਪਹਿਲਾਂ ਲੋੜੀਂਦੇ AccountType ਮੁੱਲਾਂ ਨੂੰ ਸੈਟ ਅਪ ਕਰਦੀ ਹੈ ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ findAllByUserCodes() ਪੁੱਛਗਿੱਛ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ। assertNotNull() ਅਤੇ assertTrue() ਜਾਂਚਾਂ ਨੂੰ ਜੋੜਨਾ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਰੱਦ ਜਾਂ ਗਲਤ ਮੁੱਲਾਂ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰਦੇ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਸਾਡਾ ਹੱਲ ਸਾਰੇ ਮਾਮਲਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ। ਇਸ ਸੈੱਟਅੱਪ ਦੇ ਨਾਲ, ਐਪਲੀਕੇਸ਼ਨ ਉਤਪਾਦਨ ਦੀਆਂ ਵੱਖ-ਵੱਖ ਸਥਿਤੀਆਂ ਵਿੱਚ ਐਨਮ ਸਵਾਲਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਤਿਆਰ ਹੈ। 🧪

// Problem: PostgreSQL expects specific data types in queries.
// Solution: Convert enums to strings for query compatibility with PostgreSQL.
// This Spring Boot backend solution is clear, optimized, and includes type checks.

@Entity
@Table(name = "system_accounts")
@Getter
@Setter
public class SystemAccounts {
    @Id
    @Column(name = "id", nullable = false)
    private UUID id;
    @Column(name = "user_code")
    private String userCode;  // Store as String to avoid type mismatch
}

// Enumeration for AccountType
public enum AccountType {
    PERSONAL,
    CORPORATE
}

// Repository Query with Enum Handling
@Query(value = """
    SELECT sa.id FROM system_accounts sa
    WHERE sa.user_code IN :accountTypes""", nativeQuery = true)
Optional<List<SystemAccounts>> findAllByUserCodes(@Param("accountTypes") List<String> accountTypes);
// This query accepts a List of strings to avoid casting issues.

// Convert AccountType enums to Strings in Service
List<String> accountTypeStrings = accountTypes.stream()
    .map(Enum::name)
    .collect(Collectors.toList());

// Using CriteriaBuilder to dynamically handle enums in queries with automatic type checking.
// This approach uses Java’s Criteria API to avoid type mismatches directly in the code.

public List<SystemAccounts> findAllByUserCodes(Set<AccountType> accountTypes) {
    CriteriaBuilder cb = entityManager.getCriteriaBuilder();
    CriteriaQuery<SystemAccounts> query = cb.createQuery(SystemAccounts.class);
    Root<SystemAccounts> root = query.from(SystemAccounts.class);
    Path<String> userCodePath = root.get("userCode");
    List<Predicate> predicates = new ArrayList<>();

    // Add predicates for enum values, converting to String for matching
    for (AccountType type : accountTypes) {
        predicates.add(cb.equal(userCodePath, type.name()));
    }

    query.select(root)
         .where(cb.or(predicates.toArray(new Predicate[0])));
    return entityManager.createQuery(query).getResultList();
}

// This JUnit test ensures both solutions handle enums correctly with PostgreSQL.
// Tests database retrieval for both AccountType values: PERSONAL and CORPORATE.

@SpringBootTest
public class SystemAccountsRepositoryTest {
    @Autowired
    private SystemAccountsRepository repository;

    @Test
    public void testFindAllByUserCodes() {
        Set<AccountType> accountTypes = Set.of(AccountType.PERSONAL, AccountType.CORPORATE);
        List<SystemAccounts> results = repository.findAllByUserCodes(accountTypes);

        // Verify results are returned and types match
        assertNotNull(results);
        assertTrue(results.size() > 0);
        results.forEach(account ->
            assertTrue(account.getUserCode().equals("PERSONAL") || account.getUserCode().equals("CORPORATE"))
        );
    }
}

ਸਪਰਿੰਗ ਬੂਟ ਨਾਲ PostgreSQL ਵਿੱਚ Enum ਤੋਂ ਸਟ੍ਰਿੰਗ ਪਰਿਵਰਤਨ ਨੂੰ ਸੰਭਾਲਣਾ

ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਬਸੰਤ ਬੂਟ PostgreSQL ਦੇ ਨਾਲ, ਡੇਟਾਬੇਸ ਪ੍ਰਸ਼ਨਾਂ ਵਿੱਚ ਐਨਮਜ਼ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਅਕਸਰ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ enums ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਮੂਲ SQL ਸਵਾਲ. ਮੂਲ ਰੂਪ ਵਿੱਚ, PostgreSQL Java enums ਦਾ ਸਿੱਧਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਸਦੀ ਬਜਾਏ ਇੱਕ ਅਨੁਕੂਲ ਡੇਟਾ ਕਿਸਮ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ varchar ਜਾਂ ਟੈਕਸਟ ਸਵਾਲਾਂ ਵਿੱਚ ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਸਾਨੂੰ AccountType ਵਰਗੇ enum ਦੇ ਆਧਾਰ 'ਤੇ ਨਤੀਜੇ ਫਿਲਟਰ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, PostgreSQL ਲਈ ਸਾਨੂੰ ਪੁੱਛਗਿੱਛ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ Java enum ਨੂੰ ਇੱਕ ਸਟ੍ਰਿੰਗ ਮੁੱਲ ਵਿੱਚ ਬਦਲਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਪਰਿਵਰਤਨ ਆਮ "ਓਪਰੇਟਰ ਮੌਜੂਦ ਨਹੀਂ ਹੈ" ਗਲਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਜੋ ਉਦੋਂ ਵਾਪਰਦਾ ਹੈ ਜਦੋਂ ਡੇਟਾਬੇਸ ਇੱਕ ਅਸੰਗਤ ਕਿਸਮ ਜਿਵੇਂ ਸਮਾਲਿੰਟ ਜਾਂ ਅੱਖਰ ਵੱਖ-ਵੱਖ ਨਾਲ ਇੱਕ ਐਨਮ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

ਇਸ ਮੁੱਦੇ ਨੂੰ ਸੰਭਾਲਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ ਲਾਭ ਉਠਾਉਣਾ @Enumerated(EnumType.STRING) ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਐਨੋਟੇਸ਼ਨ, ਜੋ ਕਿ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਟ੍ਰਿੰਗ ਵੈਲਯੂਜ਼ ਦੇ ਤੌਰ 'ਤੇ enums ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਨੇਟਿਵ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੇ ਦ੍ਰਿਸ਼ਾਂ ਲਈ, ਅਕਸਰ ਆਪਣੇ ਆਪ ਹੀ ਪੁੱਛਗਿੱਛ ਦੇ ਅੰਦਰ enums ਨੂੰ ਸਤਰ ਵਿੱਚ ਬਦਲਣਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ। ਵਰਗੇ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ .stream() ਅਤੇ map(Enum::name), ਅਸੀਂ ਆਪਣੇ enum ਮੁੱਲਾਂ ਲਈ ਸਟ੍ਰਿੰਗ ਪ੍ਰਸਤੁਤੀਆਂ ਦੀ ਇੱਕ ਸੂਚੀ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਾਂ, ਜਿਸ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਕਿਸਮ ਦੇ ਮੇਲ ਖਾਂਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ PostgreSQL ਨੂੰ ਪਾਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਲਚਕਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਅਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਤਰੁੱਟੀ ਦੇ ਕਈ AccountType ਮੁੱਲਾਂ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰ ਸਕਦੇ ਹਾਂ।

ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ enum ਵਰਤੋਂ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, ਇੱਕ ਹੋਰ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ CriteriaBuilder API, ਜੋ ਸਾਨੂੰ ਦਸਤੀ SQL ਲਿਖੇ ਬਿਨਾਂ ਡਾਇਨਾਮਿਕ ਤੌਰ 'ਤੇ ਟਾਈਪ-ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਵਾਲਾਂ ਦਾ ਨਿਰਮਾਣ ਕਰਨ ਦਿੰਦਾ ਹੈ। ਇਹ API ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਅਤੇ ਡੇਟਾਬੇਸ-ਅਗਨੋਸਟਿਕ ਕੋਡ ਬਣਾਉਣ ਲਈ ਉਪਯੋਗੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਐਨੂਮਸ ਨੂੰ ਅਨੁਕੂਲਿਤ ਡੇਟਾਬੇਸ ਕਿਸਮਾਂ ਵਿੱਚ ਸਵੈਚਲਿਤ ਰੂਪ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ, ਕਿਸਮ ਦੀਆਂ ਗਲਤੀਆਂ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਇਸ ਵਿਧੀ ਨਾਲ, ਪੁੱਛਗਿੱਛ ਨਿਰਮਾਣ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਅਤੇ ਡਿਵੈਲਪਰ ਵੱਖ-ਵੱਖ ਐਨੂਮ-ਅਧਾਰਿਤ ਫਿਲਟਰਾਂ ਨੂੰ ਇਕਸਾਰ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਣ ਲਈ ਲਚਕਤਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ।