[Tarantool-patches] [PATCH v2 2/3] box: make constraint operations transactional
Sergey Ostanevich
sergos at tarantool.org
Mon Dec 30 14:12:19 MSK 2019
Hi!
I didn't find any issues, let's push it.
Regards,
Sergos
On 30 Dec 00:28, Nikita Pettik wrote:
> On 29 Dec 18:51, Vladislav Shpilevoy wrote:
> > >>>> index c660b1c70..094a63ee1 100644
> > >>>> --- a/src/box/errcode.h
> > >>>> +++ b/src/box/errcode.h
> > >>>> @@ -222,7 +222,7 @@ struct errcode_record {
> > >>>> /*167 */_(ER_CREATE_FK_CONSTRAINT, "Failed to create foreign key constraint '%s': %s") \
> > >>>> /*168 */_(ER_DROP_FK_CONSTRAINT, "Failed to drop foreign key constraint '%s': %s") \
> > >>>> /*169 */_(ER_NO_SUCH_CONSTRAINT, "Constraint %s does not exist") \
> > >>>> - /*170 */_(ER_CONSTRAINT_EXISTS, "Constraint %s already exists") \
> > >>>> + /*170 */_(ER_CONSTRAINT_EXISTS, "Constraint %s '%s' already exists in space '%s'") \
> > >>>
> > >>> I'd better place type of constraint at the beggining of sentence:
> > >>>
> > >>> Check constraint xxx already exists
> > >>> Foreign key constraint ...
> > >>> Unique constraint ...
> > >>>
> > >>> Sounds way much better, doesn't it?
> > >>
> > >> It is subjective. I changed it to this order on purpose.
> > >> 1) Because I wanted to go from more common term to a more
> > >> concrete: 'Constraint' - common, <constraint type> - more
> > >> concrete, <name> - even more concrete.
> > >> 2) Because when I see '<type> constraint <name> already exists ...'
> > >> for me it looks like someone tried to create constraint of
> > >> type <type>. But it is not always so. Type is not the most
> > >> important part of the message.
> > >
> > > Well, I think it may turn out to be good argument. Why do
> > > you add type of constraint to message at all? My guess
> > > is to simplify user's life and make finding constraint
> > > with given name easy. If so, does it make sense?
> >
> > Your guess is right. I wanted to make it simpler to determine
> > with what a constraint there is a conflict. So as a user could
> > do rename of index/fk/ck/whatever-else which occupies the needed
> > name.
>
> I mean if user finds out that name is already occupied,
> one is likely to use another name rather than drop/rename
> existing constraint. In this case type of constraint is not
> vital.
>
> Anyway, patch LGTM. This is second one approve so it can be pushed,
> but Sergos wrote that he is concerned about memory management
> during constraint id creation/drop. Sergos, did you find any
> issues, or we can push this patch?
>
More information about the Tarantool-patches
mailing list