ডিবিতে কিছু উপস্থিত রয়েছে কিনা তা খতিয়ে দেখা উচিত এবং দ্রুত ব্যর্থ হওয়া বা ডিবি ব্যতিক্রমের জন্য অপেক্ষা করা উচিত

Question

দুটি শ্রেণি রয়েছে:

public class Parent 
{
    public int Id { get; set; }
    public int ChildId { get; set; }
}

public class Child { ... }

যখন দায়িত্ব অর্পণ করা ChildIdহয় তখন Parentআমি কি প্রথমে এটি ডিবিতে উপস্থিত কিনা তা পরীক্ষা করা উচিত বা ডিবি কোনও ব্যতিক্রম নিক্ষেপের জন্য অপেক্ষা করা উচিত?

উদাহরণস্বরূপ (সত্তা ফ্রেমওয়ার্ক কোর ব্যবহার করে):

উল্লেখ্য চেক এই ধরনের হয় সর্বাঙ্গে দ্য ইন্টারনেট এমনকি সরকারী Microsoft এর ডক্সে: https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using- এমভিসি / হ্যান্ডলিং-কনকুরেন্সি-সাথে-সত্তা-কাঠামো-সাথে-একটি-এস্প-নেট-এমভিসি-অ্যাপ্লিকেশন # বিভাগ-বিভাগ-নিয়ামককে পরিবর্তন করুন তবে এতে অতিরিক্ত ব্যতিক্রম হ্যান্ডলিং রয়েছেSaveChanges

এছাড়াও, নোট করুন যে এই চেকটির মূল উদ্দেশ্যটি হ'ল এপিআই-র ব্যবহারকারীর কাছে বন্ধুত্বপূর্ণ বার্তা এবং জ্ঞাত এইচটিটিপি স্থিতি ফিরিয়ে দেওয়া এবং ডাটাবেস ব্যতিক্রমগুলি সম্পূর্ণ উপেক্ষা না করা। এবং কেবল স্থানটির ব্যতিক্রম insideুকলে SaveChangesবা SaveChangesAsyncকল করা হয় ... সুতরাং যখন আপনি কল করবেন FindAsyncবা বলবেন তখন কোনও ব্যতিক্রম হবে না Any। সুতরাং যদি শিশু বিদ্যমান থাকে তবে পূর্বে মুছে ফেলা হয়েছে SaveChangesAsyncতবে সম্মতিযুক্ত ব্যতিক্রম নিক্ষেপ করা হবে।

আমি এই বাস্তবতার কারণে এটি করেছি যে " foreign key violationব্যতিক্রমী আইডি {পিতামাতার সাথে শিশু প্রদর্শন করতে ফর্ম্যাট করা ব্যতিক্রমটি আরও কঠিন hard" শিশু আইড। খুঁজে পাওয়া যায় নি।

public async Task<ActionResult<Parent>> CreateParent(Parent parent)
{
    // is this code redundant?
   // NOTE: its probably better to use Any isntead of FindAsync because FindAsync selects *, and Any selects 1
    var child = await _db.Children.FindAsync(parent.ChildId);
    if (child == null)
       return NotFound($"Child with id {parent.ChildId} could not be found.");

    _db.Parents.Add(parent);    
    await _db.SaveChangesAsync();        

    return parent;
}

বনাম:

public async Task<ActionResult<Parent>> CreateParent(Parent parent)
{
    _db.Parents.Add(parent);
    await _db.SaveChangesAsync();  // handle exception somewhere globally when child with the specified id doesn't exist...  

    return parent;
}

পোস্টগ্রাসের দ্বিতীয় উদাহরণটি 23503 foreign_key_violationত্রুটি ছুঁড়ে ফেলবে : https://www.postgresql.org/docs/9.4/static/errcodes-appendix.html

EF এর মতো ওআরএম-এ এইভাবে ব্যতিক্রমগুলি হ্যান্ডল করার খারাপ দিকটি এটি কেবল একটি নির্দিষ্ট ডাটাবেস ব্যাকএন্ডের সাথে কাজ করবে। আপনি যদি কখনও এসকিউএল সার্ভার বা অন্য কোনও কিছুতে স্যুইচ করতে চেয়েছিলেন তবে এটি আর কাজ করবে না কারণ ত্রুটি কোডটি পরিবর্তিত হবে।

শেষ-ব্যবহারকারীর জন্য ব্যতিক্রমটি সঠিকভাবে বিন্যাস করা না এমন কিছু জিনিস প্রকাশ করতে পারে যা আপনি চাইছেন না তবে বিকাশকারীরা দেখতে চান।

সম্পর্কিত:

https://stackoverflow.com/questions/6171588/preventing-race-condition-of-if-exists-update-else-insert-in-entity-framework

https://stackoverflow.com/questions/4189954/implementing-if-not-exists-insert-using-entity-framework-without-race-conditions

https://stackoverflow.com/questions/308905/should-there-be-a-transaction-for-read-queries

Comments

আপনার গবেষণা ভাগ করে নেওয়া প্রত্যেককে সহায়তা করে । আপনি কী চেষ্টা করেছেন এবং কেন এটি আপনার প্রয়োজনীয়তা মেটেনি তা আমাদের বলুন। এটি প্রমাণ করে যে আপনি নিজেকে সাহায্য করার চেষ্টা করার জন্য সময় নিয়েছেন, এটি আমাদের সুস্পষ্ট উত্তরের পুনরাবৃত্তি থেকে বাঁচায় এবং সর্বোপরি এটি আপনাকে আরও নির্দিষ্ট এবং প্রাসঙ্গিক উত্তর পেতে সহায়তা করে get কীভাবে জিজ্ঞাসা করতে হবে

— gnat

অন্যরা যেমন উল্লেখ করেছে, নোটফাউন্ডের জন্য আপনার চেকিংয়ের সাথে একই সাথে একটি রেকর্ড sertedোকানো বা মুছতে পারে এমন সম্ভাবনা রয়েছে। যে কারণে, প্রথমে চেক করা একটি অগ্রহণযোগ্য সমাধানের মতো বলে মনে হচ্ছে। যদি আপনি পোস্টগ্রাস-নির্দিষ্ট ব্যতিক্রম হ্যান্ডলিং লেখার বিষয়ে উদ্বিগ্ন হন যা অন্যান্য ডাটাবেস ব্যাকেন্ডের কাছে পোর্টেবল না হয় তবে ব্যতিক্রম হ্যান্ডলারটি এমনভাবে গঠনের চেষ্টা করুন যাতে মূল কার্যকারিতা ডেটাবেস-নির্দিষ্ট ক্লাস (এসকিউএল, পোস্টগ্রিস, ইত্যাদি) দ্বারা বাড়ানো যায়

— বিলিরিচার্ডস

মন্তব্যের মাধ্যমে খুঁজছি, আমি এই বলতে প্রয়োজন: platitudes মধ্যে স্টপ চিন্তা । "ব্যর্থ দ্রুত" কোনও বিচ্ছিন্ন নয়, প্রসঙ্গ নিয়মের বাইরে যা অন্ধভাবে অনুসরণ করা যায় বা করা উচিত। এটি থাম্ব একটি নিয়ম। আপনি কী অর্জন করতে চাইছেন তা সর্বদা বিশ্লেষণ করুন এবং তারপরে কোনও কৌশল বিবেচনা করুন যা এটি আপনাকে সেই লক্ষ্য অর্জনে সহায়তা করে কিনা। "দ্রুত ব্যর্থ" আপনাকে অনিচ্ছাকৃত পার্শ্ব প্রতিক্রিয়া প্রতিরোধ করতে সহায়তা করে। এবং তদ্ব্যতীত, "ব্যর্থ দ্রুত" এর অর্থ সত্য, "কোনও সমস্যা আছে তা সনাক্ত করার সাথে সাথেই ব্যর্থ হন।" সমস্যা সনাক্ত হওয়ার সাথে সাথে উভয় কৌশলই ব্যর্থ হয়, সুতরাং আপনাকে অবশ্যই অন্যান্য বিবেচনার দিকে নজর দিতে হবে।

— jpmc26

@ কনরাড এর সাথে ব্যতিক্রমগুলি কী করবে? আপনার কোডে বাস করে এমন কিছু হিসাবে জাতি পরিস্থিতি সম্পর্কে চিন্তাভাবনা বন্ধ করুন: এটি মহাবিশ্বের একটি সম্পত্তি। যে কোনও কিছু, যে কোনও সংস্থাকে স্পর্শ করে এটি সম্পূর্ণরূপে নিয়ন্ত্রণ করে না (যেমন ডাইরেক্ট মেমোরি অ্যাক্সেস, শেয়ার্ড মেমোরি, ডাটাবেস, আরএসটি এপিআই, ফাইল সিস্টেম ইত্যাদি) একাধিকবার এবং এটি অপরিবর্তিত হওয়ার প্রত্যাশা করে এমন একটি সম্ভাব্য রেসের শর্ত রয়েছে। হেক, আমরা সি এই এমনকি নেই সাথে মোকাবিলা আছে ব্যতিক্রম। কমপক্ষে শাখাগুলির কোনও একটি যদি সেই সংস্থার রাজ্যের সাথে মিশে যায় তবে কেবল এমন কোনও সংস্থার রাজ্যে শাখা করবেন না যা আপনি নিয়ন্ত্রণ করেন না।

— জারেড স্মিথ

@ ড্যানিয়েলপ্রাইডেন আমার প্রশ্নে আমি বলিনি যে আমি ডাটাবেস ব্যতিক্রমগুলি পরিচালনা করতে চাই না (আমি জানি যে ব্যতিক্রমগুলি অবশ্যম্ভাবী)। আমি মনে করি অনেক লোক ভুল বুঝেছিল, আমি আমার ওয়েব এপিআইয়ের জন্য বন্ধুত্বপূর্ণ ত্রুটি বার্তা (শেষ ব্যবহারকারীদের পড়ার জন্য) পছন্দ করতে চাইছিলাম Child with id {parent.ChildId} could not be found.। এবং "বিদেশী কী লঙ্ঘন" ফর্ম্যাট করা আমার মনে হয় এই ক্ষেত্রে আরও খারাপ।

— Konrad

Answer 1

বরং একটি বিভ্রান্ত প্রশ্ন, তবে হ্যাঁ আপনার প্রথমে পরীক্ষা করা উচিত এবং কেবল কোনও ডিবি ব্যতিক্রম হ্যান্ডেল করা উচিত নয়।

প্রথমত, আপনার উদাহরণে আপনি ডেটা লেয়ারে রয়েছেন, এসকিউএল চালানোর জন্য ডাটাবেসে সরাসরি ইএফ ব্যবহার করে। আপনার কোড চলমান সমান

select * from children where id = x
//if no results, perform logic
insert into parents (blah)

বিকল্পটি আপনি পরামর্শ দিচ্ছেন:

insert into parents (blah)
//if exception, perform logic

শর্তসাপেক্ষ যুক্তি সম্পাদন করতে ব্যতিক্রমটি ব্যবহার করা ধীর এবং সর্বজনীনভাবে নিম্নমানের।

আপনার একটি রেসের শর্ত রয়েছে এবং একটি লেনদেন ব্যবহার করা উচিত। তবে এটি পুরোপুরি কোডে করা যেতে পারে।

using (var transaction = new TransactionScope())
{
    var child = await _db.Children.FindAsync(parent.ChildId);
    if (child == null) 
    {
       return NotFound($"Child with id {parent.ChildId} could not be found.");
    }

    _db.Parents.Add(parent);    
    await _db.SaveChangesAsync();        
    transaction.Complete();

    return parent;
}

মূল বিষয়টি নিজেকে জিজ্ঞাসা করা:

"আপনি কি আশা করেন যে এই পরিস্থিতিটি ঘটবে?"

যদি তা না হয় তবে নিশ্চিত হয়ে সন্নিবেশ করান এবং একটি ব্যতিক্রম ছুঁড়ে দিন। তবে ঘটতে পারে এমন অন্যান্য ত্রুটির মতো কেবল ব্যতিক্রমটি পরিচালনা করুন।

যদি আপনি এটি প্রত্যাশা করে থাকেন তবে তা ব্যতিক্রমী নয় এবং আপনার সন্তানের প্রথমে উপস্থিত রয়েছে কিনা তা পরীক্ষা করে দেখা উচিত, যদি তা না হয় তবে উপযুক্ত বন্ধুত্বপূর্ণ বার্তার সাথে প্রতিক্রিয়া জানান।

সম্পাদনা করুন - এটি দেখে মনে হয় অনেক বিতর্ক আছে। আপনি বিবেচনা করার আগে বিবেচনা করুন:

উ: যদি সেখানে দুটি এফকে বাধা থাকে What কোন অবজেক্টটি অনুপস্থিত ছিল তা কাজ করার জন্য আপনি কি ব্যতিক্রম বার্তাকে পার্সিংয়ের পক্ষে সমর্থন করবেন?

বি। আপনার যদি মিস হয় তবে কেবল একটি এসকিউএল স্টেটমেন্ট চালানো হয়। এটি কেবল হিট যা দ্বিতীয় কোয়েরির অতিরিক্ত ব্যয় করে।

সি। সাধারণত আইডি একটি সারোগেট কী হবে, এমন কোনও পরিস্থিতিটি কল্পনা করা শক্ত যেখানে আপনি একজনকে চেনেন এবং আপনি এটি ডিবিতে নিশ্চিত নন pretty চেকিং অদ্ভুত হবে। তবে এর যদি কোনও প্রাকৃতিক কী ব্যবহারকারী টাইপ করে থাকে? এটি উপস্থিত না থাকার উচ্চ সম্ভাবনা থাকতে পারে

Comments

মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।

— maple_shaft

এটি সম্পূর্ণ ভুল এবং বিভ্রান্তিমূলক! এটি এমন উত্তরগুলি যা খারাপ পেশাদারদের উত্পাদন করে যা আমাকে সর্বদা বিরুদ্ধে লড়াই করতে হবে। নির্বাচন কখনই কোনও টেবিল লক করে না, তাই নির্বাচন এবং INSERT, আপডেট বা ডেল্টির মধ্যে রেকর্ডটি পরিবর্তন হতে পারে। সুতরাং এটি দুর্বল লাউস সফটওয়্যার হ'ল এবং উত্পাদনের জন্য অপেক্ষা করার জন্য একটি দুর্ঘটনা।

— ড্যানিয়েল লোবো

@ ড্যানিয়েলবো লেনদেনের কোডগুলি ঠিক করেছে

— ইভান

যদি আপনি আমাকে বিশ্বাস না করেন তবে এটি পরীক্ষা করুন

— ইওয়ান

@ ইউশা আমার এখনই কোডটি রয়েছে

— ইভান

Answer 2

স্বতন্ত্রতার জন্য পরীক্ষা করা এবং তারপরে সেটিংটি একটি অ্যান্টিপ্যাটার্ন; এটি সর্বদা ঘটতে পারে যে সময় যাচাই এবং সময় লেখার মধ্যে আইডি একসাথে concোকানো হয়। সীমাবদ্ধতা এবং লেনদেনের মতো ব্যবস্থার মাধ্যমে ডেটাবেসগুলি এই সমস্যাটি মোকাবেলায় সজ্জিত; বেশিরভাগ প্রোগ্রামিং ভাষা হয় না। অতএব, আপনি যদি ডেটা ধারাবাহিকতার মূল্য দেন, এটি বিশেষজ্ঞের কাছে রেখে দিন (ডাটাবেস), যেমন সন্নিবেশ করান এবং যদি ঘটে থাকে তবে একটি ব্যতিক্রম ধরা।

Comments

চেক করা এবং ব্যর্থ হওয়া কেবল "চেষ্টা" করার চেয়ে দ্রুত নয় এবং সর্বোত্তম আশা করি। প্রাক্তনটি 2 টি অপারেশনগুলি আপনার সিস্টেমের দ্বারা প্রয়োগ করা হবে এবং 2 ডিবি দ্বারা চালিত করা হবে, যখন সর্বশেষতম কেবল তাদের মধ্যে একটিকে বোঝায়। চেকিং ডিবি সার্ভারে অর্পণ করা হয়েছে। এটি নেটওয়ার্কে একটি কম হপ এবং ডিবি দ্বারা উপস্থিত হওয়া একটি কম টাস্ককেও বোঝায়। আমরা ভাবতে পারি যে ডিবি-র কাছে আরও একটি ক্যোয়ারী সাশ্রয়ী, তবে আমরা প্রায়শই বড় মনে করতে ভুলে যাই। একাধিকবার এবং একশো বার কোয়েরিকে ট্রিগার করার জন্য উচ্চ সম্মতিতে ভাবেন। এটি ডিবিতে পুরো ট্র্যাফিক ডুপ করতে পারে। যদি বিষয়গুলি সিদ্ধান্ত নিতে হয় আপনার উপর নির্ভর করে।

— লাইভ

@ কনরাড আমার অবস্থানটি হ'ল ডিফল্ট-সঠিক পছন্দটি এমন একটি ক্যোয়ারী যা নিজেরাই ব্যর্থ হবে এবং এটি পৃথক ক্যোয়ারী প্রাক-উড়ানের পদ্ধতির সাথে নিজেকে প্রমাণ করার পক্ষে প্রমাণের বোঝা রয়েছে। তাই আপনি: হিসাবে "একটি সমস্যা হয়ে" হয় লেনদেন ব্যবহার বা অন্যথায় নিশ্চিত যে আপনার ToCToU ত্রুটি বিরুদ্ধে নিরাপদ , ডান? আপনি যে কোডটি পোস্ট করেছেন তা থেকে এটি আমার কাছে স্পষ্ট নয় তবে আপনি যদি তা না হন তবে এটি ইতিমধ্যে একটি সমস্যা হয়ে দাঁড়িয়েছে যে টিকটিক বোমাটি আসলে বিস্ফোরণের আগেই একটি সমস্যা হয়ে দাঁড়ায়।

— mtraceur

@ কনরাড ইএফ কোর আপনার চেক এবং সন্নিবেশকে উভয়ই একটি লেনদেনের মধ্যে স্পষ্টতই রাখবেন না, আপনাকে স্পষ্টভাবে অনুরোধ করতে হবে। লেনদেন ছাড়াই, প্রথমে চেক করা অর্থহীন কারণ ডেটাবেস স্টেট চেকের মধ্যে পরিবর্তন হতে পারে এবং যাইহোক sertোকাতে পারে। এমনকি লেনদেনের পরেও আপনি পায়ের নীচে ডাটাবেস পরিবর্তন হতে বাধা দিতে পারবেন না। আমরা কয়েক বছর আগে ওরাকলের সাথে ইএফ ব্যবহার করে একটি ইস্যুতে দৌড়েছি যেখানে ডিবি যদিও এটি সমর্থন করে, সত্তা কোনও লেনদেনের মধ্যে পঠিত রেকর্ডগুলি লকিং চালনা করে না, এবং কেবল সন্নিবেশকে লেনদেন হিসাবে বিবেচনা করা হয়েছিল।

— মিঃমিন্দর

"স্বতন্ত্রতার জন্য পরীক্ষা করা এবং তারপরে সেটিংটি একটি প্রতিরোধ ব্যবস্থা" আমি এটি বলব না। এটি অন্য কোনও পরিবর্তন হচ্ছে না এবং চেকটি আরও কিছু কার্যকর ফলাফল (এমনকি কেবল একটি ত্রুটির বার্তা যা আসলে পাঠকের কাছে কিছু বোঝায়) উপস্থিত থাকে না তা নির্ভর করে আপনি নির্ভর করতে পারেন কিনা তার উপর এটি দৃ strongly়ভাবে নির্ভর করে। একটি ডাটাবেস সহকারী ওয়েব অনুরোধগুলি পরিচালনা করে, না, আপনি গ্যারান্টি দিতে পারবেন না যে অন্যান্য পরিবর্তনগুলি ঘটছে না, তবে এমন ঘটনা ঘটে যখন এটি যুক্তিসঙ্গত অনুমান হয়।

— jpmc26

প্রথমে স্বতন্ত্রতার জন্য চেক করা সম্ভাব্য ব্যর্থতাগুলি হ্যান্ডেল করার প্রয়োজনকে দূর করে না। অন্যদিকে, যদি কোনও ক্রিয়াকে বেশ কয়েকটি ক্রিয়াকলাপ সম্পাদনের প্রয়োজন হয় তবে তাদের যে কোনও একটি শুরু করার আগে সমস্তই সফল হতে পারে কিনা তা যাচাই করা প্রায়শই ক্রিয়া সম্পাদন করার চেয়ে ভাল যা সম্ভবত আবার ঘুরিয়ে দেওয়ার প্রয়োজন হতে পারে। প্রাথমিক চেকগুলি করা এমন কোনও পরিস্থিতি এড়াতে পারে না যেখানে রোলব্যাকের প্রয়োজন হবে, তবে এটি এই ধরনের ক্ষেত্রে ফ্রিকোয়েন্সি হ্রাস করতে সহায়তা করতে পারে।

— সুপারক্যাট

Answer 3

আমি মনে করি আপনি যাকে বলে "দ্রুত ব্যর্থ" এবং আমি যেটিকে কল করি তা একই নয়।

ডাটাবেসটিকে পরিবর্তন করতে এবং ব্যর্থতা পরিচালনা করতে বলছি, এটি দ্রুত। আপনার উপায় জটিল, ধীর এবং বিশেষভাবে নির্ভরযোগ্য নয়।

আপনার সেই কৌশলটি দ্রুত ব্যর্থ হয় না, এটি "প্রাকফ্লাইটিং"। কখনও কখনও ভাল কারণ আছে, কিন্তু যখন আপনি একটি ডাটাবেস ব্যবহার করবেন না।

Comments

এমন একটি ক্ষেত্রে রয়েছে যখন আপনার যখন দ্বিতীয় শ্রেণীর উপর নির্ভর করা হয় যখন একটি শ্রেণি অন্য শ্রেণীর উপর নির্ভর করে তখন আপনার মতো ক্ষেত্রে কোনও বিকল্প নেই।

— Konrad

তবে এখানে না। এবং ডাটাবেস প্রশ্নগুলি বেশ চতুর হতে পারে, তাই আমি সাধারণত "কোনও পছন্দ নয়" সন্দেহ করি।

— gnasher729

আমি মনে করি এটি অ্যাপ্লিকেশনটির উপরও নির্ভর করে, আপনি যদি এটি কেবল কয়েকটি ব্যবহারকারীর জন্য তৈরি করেন তবে এটির কোনও পার্থক্য করা উচিত নয় এবং কোডটি 2 টি ক্যোয়ারী সহ আরও পাঠযোগ্য।

— Konrad

আপনি ধরে নিচ্ছেন যে আপনার ডিবি অসঙ্গতিপূর্ণ ডেটা সঞ্চয় করছে। অন্য কথায়, দেখে মনে হচ্ছে আপনি আপনার ডিবি এবং ডেটার ধারাবাহিকতায় বিশ্বাস করেন না। যদি তা হয়ে থাকে তবে আপনার সত্যিই একটি বড় সমস্যা রয়েছে এবং আপনার সমাধানটি হ'ল একটি ওয়াকারেরআউন্ড। কাল্পনিক সমাধানটি খুব শীঘ্রই বাতিল করা হবে। আপনার নিয়ন্ত্রণ এবং ব্যবস্থাপনার বাইরে আপনি কোনও ডিবি গ্রাস করতে বাধ্য হয়েছেন এমন ক্ষেত্রেও হতে পারে। অন্যান্য অ্যাপ্লিকেশন থেকে। এই ক্ষেত্রে, আমি এই ধরনের বৈধতা বিবেচনা করব। যাইহোক, @gnasher ঠিক আছে, আপনার দ্রুত ব্যর্থ হচ্ছে না বা এটি আমরা ব্যর্থ হিসাবে দ্রুত বুঝতে পারি না।

— লাইভ

Answer 4

এটি একটি মন্তব্য হিসাবে শুরু হয়েছিল তবে খুব বড় হয়েছে।

না, অন্যান্য উত্তরগুলি যেমন বলেছে, এই প্যাটার্নটি ব্যবহার করা উচিত নয় *

অ্যাসিনক্রোনাস উপাদানগুলি ব্যবহার করে এমন সিস্টেমগুলির সাথে কাজ করার সময়, সর্বদা একটি দৌড়ের অবস্থা থাকবে যেখানে ডাটাবেস (বা ফাইল সিস্টেম, বা অন্যান্য এসিঙ্ক সিস্টেম) চেক এবং পরিবর্তনের মধ্যে পরিবর্তন হতে পারে। এই ধরণের একটি চেক কেবল নির্ভরযোগ্য উপায় নয় যে ধরণের ত্রুটি আপনি পরিচালনা করতে চান তা প্রতিরোধ করে।
পর্যাপ্ত না হওয়ার চেয়ে খারাপ, এক নজরে এটি এমন ধারণা দেয় যে এটি সুরক্ষার ভ্রান্ত ধারণা দেওয়ার সাথে নকল রেকর্ড ত্রুটিটি রোধ করা উচিত ।

যাইহোক আপনার পরিচালনা করার সময় ত্রুটি দরকার।

মন্তব্যে আপনি একাধিক উত্স থেকে ডেটা প্রয়োজন হলে কী জিজ্ঞাসা করেছেন।
এখনও না.

মৌলিক ইস্যু দূরে যেতে না কি চেক করতে চান আরো জটিল হয় তাহলে।

তবুও আপনার যে কোনও উপায়ে পরিচালনা করার ত্রুটি দরকার।

এমনকি যদি এই ত্রুটিটি আপনি যে বিশেষ ত্রুটি থেকে রক্ষা করার চেষ্টা করছেন তা প্রতিরোধের একটি নির্ভরযোগ্য উপায় হলেও অন্য ত্রুটিগুলি এখনও ঘটতে পারে। আপনি যদি ডাটাবেসের সাথে সংযোগ হারিয়ে ফেলেন, বা এটির জায়গাগুলি ফুরিয়েছে তবে কী হবে?

আপনি খুব সম্ভবত এখনও প্রয়োজন অন্যান্য ডাটাবেসের সংশ্লিষ্ট যাহাই হউক না কেন হ্যান্ডলিং ত্রুটি। এই বিশেষ ত্রুটিটি পরিচালনা করা সম্ভবত এটির একটি ছোট অংশ হওয়া উচিত।

কী পরিবর্তন করতে হবে তা নির্ধারণ করতে আপনার যদি ডেটা প্রয়োজন হয় তবে আপনার অবশ্যই এটি অন্য কোথাও থেকে সংগ্রহ করা দরকার। (আপনি কী কী কী সরঞ্জাম ব্যবহার করছেন সেগুলির উপর নির্ভর করে এটি সংগ্রহের জন্য পৃথক প্রশ্নের চেয়ে ভাল উপায়গুলি সম্ভবত) যদি আপনি সংগৃহীত ডেটা পরীক্ষা করে দেখে থাকেন যে আপনি নির্ধারণ করেন যে সর্বোপরি আপনাকে পরিবর্তন করার দরকার নেই, দুর্দান্ত, আপনি এটি তৈরি করবেন না পরিবর্তন. এই সংকল্প ত্রুটি পরিচালনার উদ্বেগ থেকে সম্পূর্ণ পৃথক।

তবুও আপনার যে কোনও উপায়ে পরিচালনা করার ত্রুটি দরকার।

আমি জানি আমি পুনরাবৃত্তি করছি তবে আমার মনে হয় এটি পরিষ্কার করা গুরুত্বপূর্ণ। আমি আগে এই গণ্ডগোল পরিষ্কার করেছি।

এটি শেষ পর্যন্ত ব্যর্থ হবে। এটি যখন ব্যর্থ হয় তখন এর নীচে পৌঁছতে অসুবিধা এবং সময় সাপেক্ষ হবে। জাতিদের পরিস্থিতি থেকে উদ্ভূত সমস্যাগুলির সমাধান করা শক্ত। এগুলি ধারাবাহিকভাবে ঘটে না, তাই বিচ্ছিন্নভাবে পুনরুত্পাদন করা এমনকি কঠিন বা এমনকি অসম্ভব। আপনি শুরু করার জন্য সঠিক ত্রুটিটি পরিচালনা করেননি যাতে আপনার সম্ভবত তেমন বেশি কিছু করতে হবে না: সম্ভবত কিছু ক্রিপ্টিক পাঠ্যের শেষ ব্যবহারকারীর প্রতিবেদন (যা আরে আপনি প্রথমে দেখার থেকে বাধা দেওয়ার চেষ্টা করছেন।) হতে পারে একটি স্ট্যাক ট্রেস যা সেই ফাংশনটির দিকে ফিরে দেখায় যে আপনি যখন এটিকে দেখেন তখন স্পষ্টভাবে অস্বীকার করে ত্রুটিটিও সম্ভব হওয়া উচিত।

* এই বিদ্যমান চেকগুলি কার্যকর করার জন্য বৈধ ব্যবসায়ের কারণ থাকতে পারে, যেমন অ্যাপ্লিকেশনটি ব্যয়বহুল কাজের প্রতিলিপি থেকে আটকাতে পারে, তবে এটি সঠিক ত্রুটি পরিচালনার জন্য উপযুক্ত প্রতিস্থাপন নয়।

Answer 5

আমি মনে করি এখানে একটি গৌণ বিষয় আছে - আপনি এটি চান এমন একটি কারণ আপনি ব্যবহারকারীর দেখার জন্য একটি ত্রুটি বার্তা ফর্ম্যাট করতে পারেন।

আমি আন্তরিকভাবে আপনাকে সুপারিশ করব যে আপনি:

ক) শেষ হওয়া ব্যবহারকারীর প্রতিটি ত্রুটির জন্য একই জেনেরিক ত্রুটি বার্তাটি দেখান ।

খ) প্রকৃত ব্যতিক্রমটি কোথাও লগইন করুন যেখানে কেবল বিকাশকারীরা অ্যাক্সেস করতে পারে (কোনও সার্ভারে থাকলে) বা অন্য কোথাও যা আপনার কাছে ত্রুটি প্রতিবেদনের সরঞ্জামের মাধ্যমে প্রেরণ করা যেতে পারে (যদি ক্লায়েন্ট মোতায়েন থাকে)

গ) আপনি তত্ক্ষণিক ব্যতিক্রম বিশদটি ফর্ম্যাট করবেন না যতক্ষণ না আপনি লগইন করেন যতক্ষণ না আপনি আরও দরকারী তথ্য যুক্ত করতে পারেন। আপনি কোনও সমস্যাটিকে ট্র্যাক করতে ব্যবহার করতে সক্ষম হবেন এমন দরকারী তথ্যের এক টুকরোটি দুর্ঘটনাক্রমে 'ফর্ম্যাট করা' করতে চান না।

---

সংক্ষেপে - ব্যতিক্রমগুলি খুব দরকারী প্রযুক্তিগত তথ্যে পূর্ণ। এর কোনওটিই শেষ ব্যবহারকারীর জন্য হওয়া উচিত নয় এবং আপনি আপনার বিপদে এই তথ্যটি হারাবেন।

Comments

"ঘটে যাওয়া প্রতিটি ত্রুটির জন্য শেষ ব্যবহারকারীকে একই জেনেরিক ত্রুটি বার্তাটি দেখান।" এটিই মূল কারণ ছিল, শেষ-ব্যবহারকারীর জন্য ব্যতিক্রমটি ফর্ম্যাট করা করণীয়কে ভীতিজনক জিনিস বলে মনে হচ্ছে ..

— কনরাড

যে কোনও যুক্তিসঙ্গত ডাটাবেস সিস্টেমে আপনার কিছু প্রোগ্রাম কেন ব্যর্থ হয়েছে তা প্রোগ্রামিকভাবে খুঁজে পেতে সক্ষম হওয়া উচিত। এটি একটি ব্যতিক্রম বার্তা পার্স করার প্রয়োজন হবে না। এবং আরও সাধারণভাবে: কে বলে যে কোনও ত্রুটি বার্তা ব্যবহারকারীর কাছে প্রদর্শন করা দরকার? আপনি সফল না হওয়া অবধি প্রথম সন্নিবেশ ব্যর্থ করতে পারেন এবং একটি লুপে আবার চেষ্টা করতে পারেন (বা পুনরায় চেষ্টা বা সময়ের কিছু সীমা পর্যন্ত)। এবং প্রকৃতপক্ষে, ব্যাকঅফ এবং পুনরায় চেষ্টা এমন কিছু যা আপনি শেষ পর্যন্ত যাইহোক বাস্তবায়ন করতে চান।

— ড্যানিয়েল প্রাইডেন