Rodrigo,
I'm doing that at database level but I'm not handling the exception because it
happens very infrequently.
The point is the validation message that I have to show like any others
validations.
Another problem is that I have more than one case like this per form.
I used the partner case but in this same form I have another nested called
company activities that can't repeat the CNAE (an activity means initial date,
final date and CNAE).
In this form I have 2 "in-memory" validations but I have others that have more
than 5 nested like this.
It will be very painfully if I have to handle each exception to discover what
nested failed and add the error by hand.
Like I said before, I see this problem happening over and over again in systems
I've worked.
But that can be an "enterprise" feature that does not fit to active record
proposal.
In that case, I will keep it as a separated gem.
I just want to be sure if I should submit a PR or something like that :)
On Aug 5, 2012, at 12:26 PM, Rodrigo Rosenfeld Rosas wrote:
> That is why constraints should be handled by databases in my opinion.
>
> Just create the unique index in the database and write something like this:
>
> begin
> company.save!
> rescue UniqueConstraintException => e # I don't really know the name for this
> exception
> render json: {error_message: "Please remove the duplicate entries."}
> rescue e # general rescuer
> log.error "Couldn't create company", e # not sure if that is the right
> syntax
> render json: {error_message: "We could't process your request. Please
> contact our support team."}
> end
>
> Well, at least this has always been my opinion and the reason why I prefer
> writing validations in the database using unique constraints or triggers.
>
> Usually the ActiveRecord and Hibernate communities among others don't
> recommend this approach if you intend to support multiple databases, but
> since I always use PostgreSQL, this is not an issue to me. That is one of the
> reasons I prefer Sequel over AR. The Sequel community will usually prefer
> handling validations in the database-level even though you can use validators
> in Ruby as well to make it easy to handle simple cases but you should always
> replicate the validations in the database level as well.
>
> Well, that is my opinion since you asked :)
>
> Cheers,
> Rodrigo.
>
> Em 05-08-2012 11:36, Gabriel Sobrinho escreveu:
>>
>> Anyone have some opinion?
>>
>> On Sunday, July 29, 2012 4:17:01 PM UTC-3, Gabriel Sobrinho wrote:
>> Hi,
>>
>> Currently uniqueness validator uses database queries which not work for
>> nested forms.
>>
>>
>> For example, I have a company form which have many partners and each partner
>> have a person and a percentage.
>>
>> Using uniqueness validator, I can not guarantee someone will not be a
>> partner two times because the partners aren't on database yet.
>>
>>
>> We've implemented a validator similar to this one:
>> http://pastie.org/private/osa3pmono5l1ykrd7vipwa
>>
>>
>> I'm not sure if the uniqueness validator should handle it.
>>
>> Take a look: http://pastie.org/private/maxdpn4gmvftzcl2ka0mq
>>
>>
>> I'm not sure if it will be too complex to the proposal of uniqueness
>> validator but that is a common validation for each system I've worked in
>> last years.
>>
>> WDYT? Something like that should be on the active record or a gem?
>>
>> Cheers,
>>
>> Gabriel Sobrinho
>> gabrielsobrinho.com
>>
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
Cheers,
Gabriel Sobrinho
gabrielsobrinho.com
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
