Laravel Vector Search اب MariaDB کو سپورٹ کرتا ہے
Laravel 13 ڈویلپرز کو MariaDB پر نیٹو (native) ویکٹر سرچ کوئریز چلانے کی اجازت دیتا ہے، جس سے PostgreSQL پر منتقل ہوئے بغیر Laravel ایکو سسٹم میں سیمنٹک سرچ (semantic-search) کی صلاحیتیں شامل ہو جاتی ہیں۔
یہ نئی سپورٹ فریم ورک کے پچھلے PostgreSQL-only امپلیمنٹیشن کی جگہ لے لیتی ہے، اس لیے اب جانا پہچانا whereVectorSimilarTo میتھڈ براہ راست MariaDB کنکشن کے ساتھ کام کرتا ہے۔ اگر آپ ریکمنڈیشن انجن، دستاویزات کی مماثلت (document-similarity) کے ٹولز، یا کوئی بھی ایسا فیچر بنا رہے ہیں جو "nearest-neighbor" لاجک پر انحصار کرتا ہے، تو یہ تبدیلی ایک بڑی رکاوٹ کو ختم کر دیتی ہے۔
یہ تبدیلی کیوں اہم ہے
Laravel کا کوئری بلڈر پہلے instanceof ٹیسٹ کے ذریعے ویکٹر سرچ کی ضرورت کا پتہ لگاتا تھا جو صرف PostgreSQL کنکشنز کو پہچانتا تھا۔ اس طریقہ کار نے اس فیچر کو ایک ہی ڈرائیور تک محدود کر دیا تھا اور کوڈ بیس میں ڈیٹا بیس کے مخصوص کنڈیشنلز (conditionals) کا ڈھیر لگا دیا تھا۔
ورژن 13 اس لاجک کو گرامر لیئر (grammar layer) میں منتقل کر دیتا ہے اور دو ڈرائیور مخصوص میتھڈز شامل کرتا ہے:
supportsVectorDistance()– Laravel کو بتاتا ہے کہ آیا موجودہ کنکشن ویکٹر فاصلوں (vector distances) کا حساب لگا سکتا ہے۔compileVectorDistanceExpression()– اس SQL فرگمنٹ (fragment) کو تیار کرتا ہے جو حساب کتاب (calculation) انجام دیتی ہے۔
ان ذمہ داریوں کو ہر ڈرائیور کے سپرد کر کے، فریم ورک "type-checking" والے ہیک کو ختم کر دیتا ہے اور مستقبل کی توسیع (extensions) کے لیے راستہ صاف کر دیتا ہے۔ اب کسی دوسرے ڈیٹا بیس کے لیے سپورٹ شامل کرنے کا مطلب کنڈیشنل بلاکس بکھیرنے کے بجائے چند ڈرائیور میتھڈز کو نافذ کرنا ہے۔
MariaDB کو نیٹو فنکشنز ملتے ہیں، MySQL کو نہیں
MariaDB میں نیٹو ویکٹر فنکشنز موجود ہوتے ہیں۔ اسٹینڈرڈ MySQL میں ان کی کمی ہے، جب تک کہ آپ کوئی ایسی مخصوص کلاؤڈ سروس استعمال نہ کریں جو AI ایکسٹینشنز فراہم کرتی ہو۔
Laravel جان بوجھ کر PHP کی سطح پر مماثلت کے حساب کتاب (similarity calculation) سے گریز کرتا ہے۔ PHP میں ویکٹرز کا حساب لگانا پیجینیشن (pagination) کو خراب کر دے گا اور ایپ کو بغیر کسی وارننگ کے سست کر دے گا۔ جب ڈرائیور آپریشن کو سنبھالنے کے قابل نہ ہو تو ایرر (error) دینا ایک محفوظ طریقہ کار فراہم کرتا ہے۔
MySQL صارفین اب کیا کر سکتے ہیں
اگر آپ کا اسٹیک سادہ MySQL پر چل رہا ہے، تو آپ کے پاس تین حقیقت پسندانہ راستے ہیں:
- MariaDB پر منتقل ہوں – زیادہ تر MySQL ورک لوڈز کے لیے یہ ایک بہترین متبادل ہے جو آپ کو اسی ایکو سسٹم میں رہتے ہوئے نیٹو ویکٹر سپورٹ فراہم کرتا ہے۔
- ایک مخصوص سرچ سروس شامل کریں – صرف مماثلت کی کوئریز کے لیے MySQL کے ساتھ ایک ہلکا پھلکا PostgreSQL انسٹنس چلائیں۔
- اس کے بغیر گزارا کریں – بہت سی ایپلی کیشنز کے لیے سیمنٹک سرچ اختیاری ہوتی ہے؛ اگر اس کا فائدہ آپریشنل لاگت سے زیادہ نہ ہو، تو MySQL پر ہی رہنا ایک عملی انتخاب ہو سکتا ہے۔
ہر آپشن کے ساتھ آپریشنل پیچیدگی، لیٹنسی (latency) اور دیکھ بھال کے اخراجات (maintenance overhead) کے حوالے سے سمجھوتہ کرنا پڑتا ہے۔ فیصلہ اس بات پر منحصر ہے کہ ویکٹر سرچ آپ کی پروڈکٹ کی ویلیو پروپوزیشن (value proposition) کے لیے کتنی مرکزی اہمیت رکھتی ہے۔
API ڈیزائن کے لیے اسباق
Laravel کی یہ تبدیلی ایک وسیع تر ڈیزائن کے اصول کی وضاحت کرتی ہے: کور لاجک (core logic) میں ڈیٹا بیس کے مخصوص چیکس کو بکھیرنے سے گریز کریں۔ جب کوئی فیچر کسی خاص انجن کی صلاحیتوں پر منحصر ہو، تو اس انحصار کو ایک ڈرائیور انٹرفیس کے پیچھے محفوظ (encapsulate) کر دیں۔ نیا گرامر پر مبنی طریقہ کار بالکل یہی کرتا ہے، جو کور کوئری بلڈر پر دوبارہ کام کیے بغیر فریم ورک کو مستقبل کی توسیع کے لیے تیار کرتا ہے۔
اپنے پیکجز بنانے والے ڈویلپرز کو اس بات کا نوٹس لینا چاہیے۔ اگر آپ کو اپنی سروس لیئر کے اندر ڈیٹا بیس کی قسم کے لیے instanceof چیک ملتے ہیں، تو اس ذمہ داری کو ڈرائیور یا ایک مخصوص اڈاپٹر (adapter) کو منتقل کر دیں۔ یہ پبلک API کو صاف رکھتا ہے اور آپ کے کوڈ کو مستقبل کے لیے محفوظ بناتا ہے۔