Hi Cookers,

I 've modifyed a Table and changed a Unique Key manualy, from 1 field (made with Builder) to 2 fields :



Now, of course I have a Save Error due to a duplicate Name



I found the Model Check Method to test the Duplicate in : admin/classes/form/rule.php
but how can i modify this to tell that my UNIQUE constraint is now on 2 fields (id_race & mname) ?

Thanks for help,
Marc

You mean for the error label ?
Hum... I have to check that. Yes you are correct, it should be managed.

This is a ticket. I need to fix that.
Stay tuned.

Hi Big Chief!

Yes, Builder not allow to manage 'Unique' for 2 fields.
May be it 's not so easy to add this functionnality in the Builder.

So, I tried to modify the check ...

I saw '$group' variable define as :
@param string $group The field name group control value. This acts as an array container for the field.

but the array $group is not tested far away in the procedure ...

so i wait for your lights ;p ...

Ok, I understand better. It is not only a question of labeling.
So, what you need is a real physical lock on the database (to make it properly)
No worries, I am on that. It is named « Primary Key »

Means that only the same combinaison of the 2 fields is not allowed.
I have been working all day yesterday for this beautiful feature coming tomorrow I think. Or tonight, but I am a bit busy today.
Also there are some changes in the SQL table declaration so I would like to test it well.

If you define primary keys (others than ID), then the ID key must become ‘INDEX’, otherwise it would not work because ID is auto incremental so any combinaison will always work.

New feature coming...
In the builder, I am actually adding the possibility to define a field as « Primary Key ». Then all the PHP part in the rule.php file has been rewrited both for « unique », and « primary key ». So that you get noticed BEFORE the SQL error of the Primary Key duplication.
On my own it already works like a charm. I only need to test it all to check possible collateral damages, but I think all is almost ok.

You will love it.

Very happy to read you and this new feature coming !

In my mind, just to exchange about that,

• You can let `id` as PRIMARY,
• And just allow to create an UNIQUE Index (one Field OR Field Group)

in order to be in this configuration : (just an example)



In the SCC Database (Société Centrale Canine) a Breeder can name a Siberian Husky as 'LIUBOV TOTO' and this name will be UNIQUE for this Breed (SH).
But this Name can be used in another Breed, German Shepherd, as 'LIUBOV TOTO' (id_race is <>)

I think it is less work for you, but if your new feature works fine, let's go !

admin wrote:
I just want to anderstand the reason why you want to break the `id` as PRIMARY_KEY ?

Because the ID is always incremental, so the UNIQUE GROUP will always pass because of this ID always different, some the combinaison would always be distinct, even when the others fields are exactly the same combinaison.

But wait... I am learning too, and I think PRIMARY KEY is NOT the solution. I have to review my code before to do the version upgrade.
After reading that : stackoverflow.com/questions/3844899/diff...y-and-index-in-mysql
I see that PRIMARY KEY should always be one ONE column only. Even if it works both in InnoDB and MySQL, this is not propper coding.
The KEY we are searching for is 'INDEX'. So, I am gonna rewrite my code (not published yet), and propose you the INDEX key.

Hold you breath a bit more. It is coming.


Well, I am still digging in that.
I thing INDEX is better than primary

Yes, you 're right, it's a better way I think.

Breaking Primary_Key 'id' is too dangerous.
And give the possibility to define a custom INDEX is just what we wait for ...

SQL STATEMENT as :

Hoping you will find the good solution

YES !!!
Thank you. I was searching again because INDEX is not an 'UNIQUE' statement. So not working either...
But anyways I keep it for proposal because it is good one for optimisation.

So, I continue to dig. It is bigger deal than I tought. Maybe tomorrow, maybe later, but I am on this until it is working and finished.

It takes longer than expected because I am writing the interface for it.
But it is in a good way.

I have been rewriting many times, for finally create a new wizard for that.
It will even be possible to make differents groups on the same table.

Unlimited... as usual.

Yeah ... Great news !

I think I won't be alone to love it

Job done.

You will be my beta tester.
In the W-E I will put the missing icon, and I will write the article to explain the feature.

In the meantime, you can test it...
Instance the new wizard (Unique Group), drag the concerned fields in it, and then... here we are !

Normally, you get :
- the database declaration (real physical lock)
- the class/form/rule.php file wich handle the error
- the XML fields wich contain the informations for the component to catch the error before SQL

You can even make as many groups as you want.
It should work without problem, but it is not properly finished because the keys in SQL has a limit size, and so if you overload this limit. Boom.

Also, you will find a small new feature wich allow a field to be 'INDEX'. For DB optimisation. (I was digging for unique feature, and I though cool to add that one as well)
To define an index it in located in the field's properties. (an index replace the unique feature)

The primary keys are left untouched. That was a mistake to talk about that.

Hope you like it.
Cheers.

Great new feature, missed it a couple of time!

Well done !

I have updated my 2 Tables, adding my Unique Key ( with 2 fields ) and start testing ...

In the SandBox, this new feature works fine for me. The couple of fields is now protected. But an SQL Error is displaying to report the Duplicate Entry.


I downloaded and replaced the new concerned files in my current component (2 xml files and rule.php)

Same thing on my localhost, SQL Error comes up before the test procedure ($duplicate).
It's late, I will follow/check the code tomorrow ...

I think it is nothing, thanks again for this add-on

I think I forgot something.

In the concerned XML fields, check if you have the 'validate' value.


When validate is 'numeric', or other rule... no problem.
When you don't have any particular rule, it should be validate="default" for testing this unique group feature.

validate is not always required, but for this new feature, I thing I forgot to set it to "default".

Hope it helps.