ক্ষেত্রগুলির পরিমাপযোগ্যতার প্রসঙ্গে নতুন ক্ষেত্র তৈরির তুলনায় ক্ষেত্রগুলির পুনরায় ব্যবহারের মধ্যে একটি ভাল ভারসাম্য কী?


34

আমি একটি ওয়েবসাইটে নিম্নলিখিত বাক্যটি পড়েছি:

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

এবং কিছু সন্দেহ দেখা দেয়।

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

আর্কিটেকচার করার সময় কতটি সারি একটি বুদ্ধিমান সর্বাধিক লক্ষ্য হতে পারে? এইভাবে আমরা সিদ্ধান্ত নিতে পারি কখন ক্ষেত্রগুলি পুনরায় ব্যবহার করতে হবে এবং কখন নতুন তৈরি করতে হবে (যদিও পুনরায় ব্যবহারের সুযোগ রয়েছে)।


6
আমি উত্তরগুলি প্রকৃত মেট্রিকগুলির সাথে ব্যাক আপ দেখতে দেখতে চাই।
এমপিডোনাদিও

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

উত্তর:


24

কোনও ক্ষেত্রের ডেটার পরিমাণ সাধারণত কোনও সমস্যা হয় না। যদি আপনি এটি সম্পর্কে উদ্বিগ্ন হন তবে বিকল্প ক্ষেত্রের সঞ্চয়স্থান প্লাগইনগুলি সন্ধান করুন বা আপনার নিজের লিখুন। উদাহরণস্বরূপ মঙ্গোডিবি , যা এতে আপনি রেখে দেওয়া বেশিরভাগ কিছুই মোকাবেলা করতে পারে। এটি উদাহরণস্বরূপ http://examiner.com এ ব্যবহৃত ।

একটি বাস্তব সমস্যা তবে ক্ষেত্র আপনি সংখ্যা। কারণ বর্তমানে ড্রুপাল in-এ, সমস্ত ক্ষেত্রের সম্পূর্ণ ক্ষেত্রের কনফিগারেশন, সেগুলি লোড করা আছে বা না থাকুক, প্রতিটি একক অনুরোধে ক্যাশে থেকে আনা হয়েছে।

আমি 250+ ক্ষেত্র সহ এমন সাইটগুলি দেখেছি যেখানে ফিল্ড কনফিগারেশনটি লোড করা এবং আনসিরিয়ালাইজেশন করতে 13MB + মেমরি লাগে।

সম্পাদনা করুন: দ্রুপাল .2.২২ সহ ক্ষেত্রের তথ্য ক্যাশে উন্নত করা হয়েছে ( বিশদ জন্য http://drupal.org/node/1040790 দেখুন) কেবলমাত্র নির্দিষ্ট পৃষ্ঠায় প্রদর্শিত বান্ডিলের ক্ষেত্রগুলি ক্যাশে থেকে লোড করা হয়েছে এবং সেগুলি রয়েছে পৃথক ক্যাশে এন্ট্রি। এটি কেবলমাত্র তখনই কার্যকর হয় যখন একাধিক বান্ডিল জুড়ে অনুরোধের দৃষ্টান্তগুলির জন্য কোনও ভুল এপিআই কল নেই।


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

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

এটি বলেছে, কম বেশি মুঠোয় ক্ষেত্র থাকার ফলে কোনও তাত্পর্য হবে না তাই যদি আপনি সেভাবে আরও স্বাচ্ছন্দ্য বোধ করেন তবে সমস্যা হওয়া উচিত নয়।
বার্দির 14

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

এই এখন আর তা নেই: drupal.org/node/1040790
jackbravo

13

আমি মোটামুটি বার্ডিরের সাথে একমত কয়েক নোডের লক্ষ লক্ষ সারি এবং 30-40 ক্ষেত্র সহ একটি প্রকল্পের সাথে আমার অভিজ্ঞতাগুলি এখানে রয়েছে।

  1. ক্ষেত্র সারণীতে সারি সংখ্যা পড়ার পারফরম্যান্সের জন্য বড় সমস্যা নয়, কারণ সমস্ত ক্ষেত্র প্রাথমিক কী দ্বারা আনা হয়।
  2. নতুন নোড লেখার সময় নোড টাইপের প্রতি ক্ষেত্রের সংখ্যা দ্রুত বড় পারফরম্যান্স সমস্যায় পরিণত হতে পারে। একটি নোডের জন্য 30+ ক্ষেত্র থাকা যখন আপনি একটি নতুন নোড তৈরি করেন তখন 60+ INSERT বিবৃতিতে ফলাফল হয় । এটি সম্পূর্ণ হতে কয়েক সেকেন্ড সময় নেয়। আপনি যদি ব্যবহারকারীদের প্রচুর ডেটা তৈরি করেন তবে এটি আপনার পারফরম্যান্সকে আঘাত করবে। 1000 নোডের বাল্ক সন্নিবেশগুলিতে প্রায় এক ঘন্টা সময় লাগবে। আপনার যদি 100'000 নোড আপডেট করতে হয় তবে এটি একটি বড় সমস্যা।
  3. আপনি যদি মনে করেন যে ক্ষেত্রগুলির সংখ্যা আপনাকে আঘাত করতে চলেছে, আপনার নিজের ফিল্ড স্টোরেজ লেখার বিষয়ে গুরুত্ব সহকারে চিন্তা করা উচিত বা কেবল ক্ষেত্রগুলি ব্যবহার করবেন না। (আপনি কিছু অতিরিক্ত প্রচেষ্টা সহ দর্শনগুলি নিয়ে আপনার নোডকে এখনও কাজ করতে পারেন))
  4. মঙ্গোডিবি সম্পর্কে একটি শব্দ। এটি একটি খুব আকর্ষণীয় প্রকল্প এবং আমি আশা করি এটি বড় ডিবিগুলির অলিম্পে পরিণত করবে। দুর্ভাগ্যক্রমে মাইএসকিএল বা পিজএসকিএল এর পরিপক্কতার সাথে তুলনা করা এটি একটি শিশু। একটি খুব তরুণ পণ্য মোকাবেলা করার জন্য প্রস্তুত থাকুন।

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

5

আপনি যদি সত্যিই চিন্তিত হন যা ঘটেছিল তবে আমি মনে করি একটি সিমুলেশন ঠিক আছে।

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

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

সিমুলেশনগুলি কখনই নিখুঁত হয় না, তবে তারা আপনাকে সঠিক দিকে যেতে পারে।


2

সারণীতে প্রতিটি ক্ষেত্রের প্রতিটি একক সারণি ক্ষেত্রে সূচীর ব্যবহারে ক্ষেত্রগুলিতে স্কেলাবিলিটি সহ একটি ইস্যু। প্রাথমিক কী ক্লাস্টারড সূচকটি বেশিরভাগ ক্ষেত্রের সংমিশ্রণ, তারপরে এটি প্রতিটি ক্ষেত্রের পৃথক পৃথক সূচক তৈরি করে। সূচকগুলি ডাটাবেসের জন্য এক টন ওভারহেড রচনা তৈরি করে এবং বেশিরভাগ ক্ষেত্রে কখনও ব্যবহার হয় না।


2

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

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

অনুরূপ নোড বৈশিষ্ট্যের কারণে এটি টেমপ্লেট তৈরিও সহজ করতে পারে।


1

কেবল আমার গল্পটি ভাগ করেই, আমরা ড্রুপাল কমার্স ব্যবহার করছি এবং আমাদের পণ্যের প্রকরণে (স্কু) প্রায় 40 টি ক্ষেত্র রয়েছে এবং তারপরে আমাদের পণ্য প্রদর্শনে আরও 460 (হ্যাঁ, পাগল) রয়েছে। আমাদের কাছে কিছু পণ্য তুলনা মতামত ছিল যা এই ক্ষেত্রগুলির সকলকে দেখবে। ক্যাশে না করে কিছু পৃষ্ঠাগুলি এক মিনিট সময় নিতে পারে!

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

আমরা এতগুলি ক্ষেত্রের সাথে আমরা যে প্রধান সমস্যাটি নিয়েছিলাম সেটি হ'ল ডিসপ্লে স্যুটটি হ'ল এটি খুব ধীর হয়ে উঠবে (কিছু সময় অ-প্রতিক্রিয়াশীল) যদি আমরা কোনও ক্ষেত্রকে পুনরায় সাজানোর বা স্থানান্তরিত করার চেষ্টা করি।

ভাগ্যক্রমে, আমরা আমাদের পণ্যগুলি কিছুটা ফ্যাক্টর করার সিদ্ধান্ত নিয়েছি যাতে আমরা আশা করি যে আমাদের সর্বাধিক জটিল ক্ষেত্রগুলির জন্য 200-250 সীমাতে আমাদের সর্বাধিক ক্ষেত্রগুলি নামতে পারি (আমরা বৈজ্ঞানিক উপকরণে রয়েছি, সুতরাং জটিল পরিমাপ এবং চশমা প্রয়োজন) ।


0

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

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


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

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

0

আমি এখনও অবধি সর্বদা ক্ষেত্রগুলি পুনরায় ব্যবহার করছি কিন্তু এখন নতুন প্রকল্পের জন্য নোড প্রকারে অনন্য ক্ষেত্রগুলি ব্যবহার করার কথা ভাবছি। আমি প্রকৃতপক্ষে প্রতিটি সত্তার বান্ডিলের জন্য সবকিছু সুন্দরভাবে আলাদাভাবে রাখতে চাই (ক্ষেত্র, দর্শন, নিয়ম, প্রসঙ্গ, ইত্যাদি)। সুতরাং এটি স্কেলেযোগ্যতার প্রশ্ন উত্থাপন করেছিল যা আমাকে এখানে নিয়ে গেছে led আমি বার্ডিরের সম্পাদনায় সান্ত্বনা পেয়েছি (ক্ষেত্রের তথ্য ক্যাশেটি উন্নত করা হয়েছে ( বিশদের জন্য http://drupal.org/node/1040790 দেখুন) দ্রুপাল .2.২২ সহ, কেবলমাত্র একটি নির্দিষ্ট পৃষ্ঠায় প্রদর্শিত বান্ডিলগুলির ক্ষেত্রগুলি এখানে থেকে লোড করা হয়েছে ক্যাশে এবং তারা পৃথক ক্যাশে এন্ট্রি। এটি কেবলমাত্র তখনই কার্যকর হয় যদি কোনও ভুল এপিআই কল না থাকে যা একাধিক বান্ডেল জুড়ে অনুরোধের অনুরোধ করে)।

আমি কেবল এটি উল্লেখ করতে চাই যে আমি খুব আকর্ষণীয় মডিউলটি করেছি যা আমি একাধিক, জটিল সাইটগুলিতে কয়েক মাস ধরে ব্যবহার করে আসছি htt https://www.drupal.org/project/render_cache । এটি আমার মতে লুকানো রত্নগুলির মধ্যে একটি।

প্রকল্পের পৃষ্ঠায় যেমন বলা হয়েছে, মন্তব্যের অংশটি আসলে ডিও-তে ব্যবহৃত হচ্ছে।

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


-3

আমার পরামর্শ অনুসারে পৃথক সামগ্রী প্রকারে একই ক্ষেত্রগুলি ব্যবহার করা ভাল ধারণা। কারণ এটি আপনার সাইটের কার্যকারিতা উন্নত করবে। ড্রুপাল In-এ, আপনি যখন সেই সময় নির্বাচন অপারেশনটি ব্যবহার করছেন, তখন সামগ্রীর ধরণের ক্ষেত্রে একই ক্ষেত্রগুলি ব্যবহার করা আপনার ড্রুপাল site সাইটে সত্যই কার্যকর।


1
ড্রুপাল 7-এ, তারা মতবাদ ORM ব্যবহার শুরু করেছেন ... না তারা করেনি। ড্রুপাল 8 এমনকি মতবাদও ব্যবহার করে না
ক্লাইভ

"মতবাদ সর্বদা সমস্ত ম্যাপযুক্ত ডেটা থেকে বস্তুটি ফেরত দেয়", এটিও একটি মিথ্যা বক্তব্য। ডিফল্ট আচরণটি উপযুক্ত নয় এমন মতবাদের প্রতি ইঙ্গিত দেওয়ার জন্য অবজেক্টগুলি টীকায়িত করা যেতে পারে। ক্লাইভ যেমন বলেছে যে, এটি মারাত্মকভাবে প্রাসঙ্গিক নয়, ড্রুপাল মতবাদ ব্যবহার করেন না।
লেটারিয়ান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.