Hi,
Thanks a lot! The patch looks good. It's great to have good test cases!
I did make the following changes:
* Source code formatting / spaces: "} else {" instead of "}else{" and ") {"
instead of "){". To automatically find those places, I use Checkstyle, with
the configuration at src/installer/checkstyle.xml.
* There was quite some code duplication, for example in GrantRevoke. I
refactored the code. This also reduces the method count on RightOwner and
Right. There are now some ugly "instanceof" checks, but much less duplicate
code. At some point we might want to have rights for other database
objects; this is now much simpler to support.
* Parser: currentToken and read() shouldn't be used if possible. Instead,
simply use readAliasIdentifier(), which is simpler, and does a bit more (it
throws an exception for non-identifiers).
I'm still working on this, and will commit it once it's done.
Regards,
Thomas
On Wednesday, April 15, 2015, Fred&Dani&Pandora&Aquiles <[email protected]>
wrote:
> Hi,
>
> I changed the patch to accomplish the expected behavior. Now the rights on
> a schema will be valid for any table of the related schema in any time.
> Besides, it's worth to note that the rights on a schema takes precedence
> over the rights in the table. Let me know if I'm in the right way and/or if
> is missing something.
>
> Regards,
>
> Fred
>
> 2015-04-12 7:05 GMT-03:00 Fred&Dani&Pandora&Aquiles <[email protected]>:
>
>> Hi Rami,
>>
>> I have implemented for myown use a user defined function that has the
>>> following syntax:
>>> F.GRANT_RIGHTS('comma_separated_list_of_rights',
>>> '*|comma_separated_list_of_schemas', '*|comma_separated_list_of_users')
>>> With this you can grant a set of rights to any number of schemas to any
>>> number of users.
>>> The implementation was 30-40 lines.
>>>
>>> The problem is that when I do development I have to run my GRANT_RIGHTS
>>> statement over and over again when I drop and recreate a table (with some
>>> changes).
>>> So the useful feature would be that giving rights to all objects in a
>>> schema would mean all objects now and in the future.
>>>
>>
>> I think the MySQL implements such feature.
>>
>> If someone else starts creating new tables in the same db for some other
>>> purpose then it would make sense that he would create a new schema for that
>>> new purpose, no?
>>>
>>
>> I have cases in my job that fits in my previous post, where there are
>> schemas shared by different users, but not all tables in the related
>> schemas are necessarily shared. My main concern is about privileges be
>> granted automatically and some changes be executed by unexpected users. On
>> the other hand, I agree (by ignoring my previous concern) that would be
>> very helpful the permissions in the schema be valid for the related tables
>> in any time.
>>
>> Regards,
>>
>> Fred
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "H2 Database" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/h2-database.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
