Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #2324 (closed defect: fixed)

Opened 10 years ago

Last modified 9 years ago

Increase length of Permission.permission_name

Reported by: pitrou Owned by:
Priority: normal Milestone: 2.1b1
Component: TurboGears Version: 2.0b7
Severity: trivial Keywords:
Cc:

Description

It can be useful to give meaningful names to permissions (for example "modify_commercial_info"). The current limitation of Permission.permission_name to a 16-character Unicode field can then be annoying, and probably doesn't have any advantage in itself. I suggest increasing it to e.g. 255, so that people can put whatever they want in it.

Change History

comment:1 in reply to: ↑ description Changed 10 years ago by Gustavo

Replying to pitrou:

It can be useful to give meaningful names to permissions (for example "modify_commercial_info"). The current limitation of Permission.permission_name to a 16-character Unicode field can then be annoying, and probably doesn't have any advantage in itself. I suggest increasing it to e.g. 255, so that people can put whatever they want in it.

-1. It'd just make queries slower with no benefit -- if it's a real limitation to you, you can always increase it.

comment:2 follow-up: ↓ 3 Changed 10 years ago by pitrou

Slower?? I'm not sure why you say that... Do you know how a VARCHAR column works?

comment:4 follow-up: ↓ 5 Changed 10 years ago by pitrou

I question both the meaning and relevance you give to these documents:

  • The Oracle example is for a table of 8,388,608 rows (!)
  • The MySQL doc says "When MySQL will need to do the sort it will use corresponding fixed length field format, which will lead to larger temporary file and so slower sorting.". Sure, but you don't sort permissions by permission_name. Actually, you don't sort permissions at all.
  • As for the MS SQL docs, they don't explicitly state that VARCHAR with a large size are a bad thing. They seem to talk about size of fixed-length columns.

In any case, the fact that a typical application will only have 5 to 10 different permissions, and the richest applications perhaps 50 to 100 of them, seems to make the whole objection gratuitous. Querying such a data set will be blazingly fast, whatever the exact column types, on any decent DBMS.

Ironically, the fact that no Index is defined in model/auth.py is probably much more detrimental to performance (for non-trivial datasets) than the size of the various columns. (PostgreSQL doesn't automatically create an index for each foreign key ; you have to manually create indexes yourself if you want to speed up joins along those foreign keys. "EXPLAIN SELECT" tells me that currently, PostgreSQL will do a sequential scan when joining between the various auth tables)

comment:5 in reply to: ↑ 4 Changed 10 years ago by Gustavo

Replying to pitrou:

I question both the meaning and relevance you give to these documents:

  • The Oracle example is for a table of 8,388,608 rows (!)

Well, benchmarks always use big values to make differences notable.

  • The MySQL doc says "When MySQL will need to do the sort it will use corresponding fixed length field format, which will lead to larger temporary file and so slower sorting.". Sure, but you don't sort permissions by permission_name. Actually, you don't sort permissions at all.

Good point, it was a bad reference in this context.

  • As for the MS SQL docs, they don't explicitly state that VARCHAR with a large size are a bad thing. They seem to talk about size of fixed-length columns.

"The narrower the column, the less amount of data SQL Server has to store, and the faster SQL Server is able to read and write data"... That doesn't refer to fixed-length columns.

In any case, the fact that a typical application will only have 5 to 10 different permissions, and the richest applications perhaps 50 to 100 of them, seems to make the whole objection gratuitous. Querying such a data set will be blazingly fast, whatever the exact column types, on any decent DBMS.

The column size does affect performance, at least a little bit. So, I think it's good to have a narrow column by default... After all, developers will always be able to change that.

I'm not strongly opposed to increasing it, though. If more people think it should be increased, it'd be fine by me.

Ironically, the fact that no Index is defined in model/auth.py is probably much more detrimental to performance (for non-trivial datasets) than the size of the various columns. (PostgreSQL doesn't automatically create an index for each foreign key ; you have to manually create indexes yourself if you want to speed up joins along those foreign keys. "EXPLAIN SELECT" tells me that currently, PostgreSQL will do a sequential scan when joining between the various auth tables)

That's indeed a good point, could you please open another ticket for that, so we won't forget? I could do it, but I'm a rush now

comment:6 Changed 10 years ago by percious

It makes sense to me that 16 chars is insufficient to describe an entire permission, but 256 may be a tad on the verbose side. Let's say we compromise and increase to 64 chars?

cheers. -chris

comment:7 Changed 10 years ago by jorge.vargas

  • Milestone set to 2.1

I agree with pitrou the performance hit is probably irrelevant here. And I also think it should be bigger by default. 16 is too slow. yet 255 is too big. How about 32? 64 at most. I can't think of a name big enough to not fit there. Also note the display name is bigger. It should also be consistent in Permission, Group and Username.

Also keep in mind this is just a sane default the whole point of it being a template is for you to fix it if you don't like it.

comment:8 Changed 9 years ago by percious

  • Milestone changed from 2.1 to 2.1b1

comment:9 Changed 9 years ago by percious

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.