Request for Enhanced Validation Rules: is_unique and is_not_unique

The is_unique and is_not_unique validation rules offer robust ways to ensure data integrity when checking for the uniqueness or existence of values within a specific table. 
However, there's a scenario where the current implementation can be further enhanced, particularly when dealing with multiple database groups (dbGroup) in a model with foreign keys from different databases.

Current Validation Rules

1. is_not_unique
   The is_not_unique rule checks the database to see if a value exists in a specified table and field. It allows filtering based on one field and value.
   
   PHP Code:

   is_not_unique[table.field,where_field,where_value] 

   Example:
   
   PHP Code:

   'email' => 'is_not_unique[users.email,id,123]' 

   
   
2. is_unique
   The is_unique rule checks if the field's value is unique within the database. It can optionally ignore a specific record by field and value, which is useful when updating records.
   
   PHP Code:

   is_unique[table.field,ignore_field,ignore_value] 

   Example:
   
   PHP Code:

   'username' => 'is_unique[users.username,id,5]' 


Proposed Enhancement: Supporting Multiple dbGroup

In many real-world applications, models can involve multiple foreign keys referencing tables in different database groups. To streamline the validation process, I propose introducing support for a database group (dbGroup) prefix within the is_unique and is_not_unique rules. This would allow developers to specify the database group directly in the validation rule, improving flexibility and reducing complexity in code that handles multiple databases.

Example: 

Consider a scenario where you have two foreign keys in a model, each pointing to different databases:

• dbGroup1 contains a users table.
  
• dbGroup2 contains a customers table.
  

Here’s how the validation rule might look for checking uniqueness within dbGroup1 and dbGroup2:

PHP Code:

'email' => 'is_unique[dbGroup1.users.email,id,123]',
'customer_code' => 'is_not_unique[dbGroup2.customers.code,id,456]' 


This implementation would ensure that the validation rule queries the correct database group, which is particularly useful when working with multiple data sources.


Priority of dbGroup
In this proposal, the priority of which dbGroup is used during validation would follow a clear order:

• Highest Priority: If the dbGroup is specified in the validation rule itself, such as is_unique[dbGroup1.users.email,id,123], this database group takes precedence.
  
• Next Priority: If the dbGroup is not specified in the rule, then the dbGroup parameter passed to the run() method during validation will be used: $this->validate($rules, null, 'dbGroup2');
  
• Default: If neither the validation rule nor the run() method specifies a dbGroup, the default database connection will be used.
  

Conclusion:
The proposed enhancement to the is_unique and is_not_unique validation rules by allowing the optional inclusion of dbGroup would greatly simplify validation for models that span multiple database groups. This enhancement aligns well with CodeIgniter's existing feature of specifying dbGroup in the run() method for validation.

I believe this improvement would enhance the developer experience, reduce boilerplate code, and offer greater flexibility in managing complex database structures.
Feel free to share your thoughts and any feedback on this proposal.

I am sure the developers would gladly consider a PR with the proposed changes,

The very small developer team is focused on maintaining & refining the current code & features. Open source projects such as this depend on other users to enhance functionality.

Everything is great. But you're talking about a lot of developers.
Forum and repository activity are low. Will this feature be useful to everyone?
To begin with, you can create your own validation function or show a PR

Simple CI 4 project for beginners codeigniter-expenses ( topic )

Everything is great. But you're talking about a lot of developers.
Forum and repository activity are low. Will this feature be useful to everyone?
To begin with, you can create your own validation function or show a PR

Thank you for your feedback! 
I've already created a PR with my suggestion: PR #9216. Feel free to take a look!