can't assign theme to sub albums with long names

george2

i have a lot of long keyword rich dirs (61 chars+) which i've taken the time to create. when i try to assign a theme to them, i get this error:

Zenphoto Error
MySQL Query ( CREATE TABLE IF NOT EXISTS `zp_very_long_dir_name_options` ( `id` int(11) unsigned NOT NULL auto_increment, `name` varchar(64) NOT NULL, `value` text NOT NULL, PRIMARY KEY (`id`), UNIQUE (`name`) ); ) Failed. Error:Incorrect table name 'zp_very_long_dir_name_options'

why is it trying to create a table?

EDIT: am i right in assuming zp creates a table for each album that has a theme assigned to it? so, if i have 1000 albums all assigned to various themes which i'm close to (scalability and all that...)

it just isn't realistic or...good design. as it stores name value pairs, so how about a table:

theme_options (int id primary key auto_increment, int albumid, varchar(255) name, varchar(255) value)?
with a unique key on albumid and name, and index on albumid?

acrylian

Because album themes can have different option settings than the rest of the gallery and need therefore a extra table.

george2

sure, understand that, but why a new table? why not just create a separate table for each album... because, well you wouldn't. the tables store the same information as the others, just for different galleries. there is no sense in having a separate table for the theme options for each album.

sbillard

"but why a new table? why not just create a separate table for each album"

You have to be kidding, right? What is the difference between a "new" table for the album vs. "a separate table for each album"?

If you know a better way to implement Zenphoto, why don't you take a branch of the code and make your changes. But hurry, do it while you still know everything.

george2

so you think it's acceptable that i can't assign themes to a lot of albums because you can't create a table.

and, a database with 1000 tables for each album that's themed. and that's acceptable to you? omg. yes i was kidding, but unfortunately you're not. this really is a a serious downer for me. it is bad database design. think about scalability. if you have 2000 albums, and you want to theme 50% of them. damn that's a lot of tables, when one table could hold all the info.

yes it would involve a lot of database and core changes, but, well i can only echo incredibly poor database design. [sarcasm]heck why bother having keys in a database, when you can just call a table the name of the album, and store the album data in there. it'd be better than having one table with all the album info having to sort through right?[/sarcasm] that's exactly what you're doing here. albums don't have a unique id for nothing.

and make a branch? no way. there are quite a few major performance hits zp has which i've overlooked, but this has really hit the rtfm limit. i'm going to have to start from scratch

sorry for being blunt, but any other programmer would tell you the same.

trisweb

Sbillard, your response was out of line here. At times users' suggestions are in fact correct, and even if they aren't they deserve respect. I believe he meant a "new set of rows" rather than a new table, clearly he's averse to creating new tables for each album.

I have to (strongly) agree with george here, creating a table for each themed album is unnecessary and inefficient. That is very poor database design; one table per any datum is just not done, for many good reasons, one of them being the very reason brought up originally in this thread - you want to have a predefined (or at least predictable) set of tables, not a variable one.

Albums have ids, simply create a second column in the options table for the album ID associated with the option and create option rows as needed. Absolutely no need to create new tables.

george2, I apologize for the many issues you see in zenphoto that impact performance or correct design. I've had to sort of let it go in favor of allowing the project to move forward, but I'm sure you'll agree that at some point, continuing development is better than keeping it 100% correct but stagnant and incomplete.

george3

it would appear that someone banned / muted george2 because they didn't like what he was saying... though actually, they should know he was right, as confirmed by trisweb.

that unnecessary table creation was a downer, banning someone because he gave constructive criticism is pathetic i'm afraid. sbilliard / acrynin, whoever muted / banned me needs to learn to take criticism, i explained the why, and how to fix.

apart from one, i didn't get a single thanks for all the fixes i submitted. i added thumbnail creation from ffmpeg - a big addition - and nothing has happened there.

anyway, i'm well into my own system now, so good luck with this zp. it looks like trisweb will be having to re-plan and organise a rewrite sometime soon because someone didn't pay attention in database 101.

acrylian

Just to make it clear: To my knowledge no one has banned you, and surely noone would do because you say your opinion. We welcome that. I don't have a problem with that or with taking critism. I don't claim to be perfect or to be the best coder in town.

What I actually have a problem with recently is the way you say these things. I can't judge if it's intended or not, but your posts appear to me a little arrogant. As we all know written text can be easily missunderstood. And probably sbillard was a little to harsh, too.
But even if you are right in this case (we already talked in the team about it), I find that tone a little inappropiate for someone who is just on this forum for a week while we are on the project it a little longer.

apart from one, i didn't get a single thanks for all the fixes i submitted. i added thumbnail creation from ffmpeg - a big addition - and nothing has happened there.
Sorry, that is exactly the behavior I meant above. We are a very small team (3 active coding devs and one that is helping with other things) and we can't always react or implement those things at once andI didn't have the time to look at it yet. We do this all here as volunteers in our spare time. Some people need to be reminded of that some times...

It's simply not true that you are not recognized for your fixes. We had a conversation on especially that ticket you mention, remember? Just to remind I cite myself: "This will be a good addition". And I cite sbillard "ZP looks for images with the same name as videos and as you surmize, does not put them in the database. Your approach is a good one." That is both overly positive. Ok, you didn't get a medal for the "fix of the week", but nobody ever did...:-)

So could we please calm down a little?

trisweb

I think he's plenty calm, let's not escalate this further.

He has every right to say the things he says in the way he says them after how he was responded to in this thread. Acrylian, perhaps it is a language barrier, but I don't see anything wrong.

George, one thing you do need to understand that Acrylian made clear is that we are a small team and don't have the time or energy to deal with patches or issues immediately. They sometimes will sit in the tracker for a while before they're used, but that doesn't mean we don't appreciate them. We simply also ask that you give us the same respect for donating our time and money to a free and open project, and have no undue expectations of that.

One other point I want to mention is that just because there's an issue with one feature, or a wrong implementation in one place, does not mean the whole package is wrong. The great majority of Zenphoto is correct and elegant, I assure you. There are a few bugs and places to clean up, but in the end, it's still a good product.