determine if anime has started/finished for voting [DENIED]

[pelican]

A date should be considered to have passed at least one day before it actually does to allow for differences in timezones.

An explicit start date in the anime's record can either override everything or be the last resort test. I'd prefer the latter, and despite knowing that I'm probably alone in this opinion, my logic places this test last. Move it to first if you like.

The algorithm follows; stop as soon as you are told that voting is allowed or disallowed:

1. Permanent voting: if total number of episodes is not known, go to 5.
2. If episode (permanent: <episode count> | temporary: 1) has no entry in the database, go to 5.
3. If the episode has a release date: voting is allowed if it has passed and disallowed if not.
4. If the episode has any (real, not generic) files...
   1. ...and all of them have release dates: voting is allowed if any of them have passed, disallowed if none have.
   2. Otherwise, voting is allowed.
5. If anime has (permanent: end | temporary: start) date and this has passed, allow voting.
6. Disallow voting.

Formulating this in SQL is an exercise for the reader, though a simple one.

[exp]

Formulating this in SQL is an exercise for the reader, though a simple one.

don't be so sure about that.
you have to keep in mind that performance is always an issue.
and the anime page is the most requested page type on anidb.
every additional query for the anime page hurts anidb, so they have
to be worth the extra load if they're going to be implemented.

well anyway, it has been decided that no action will be taken for the
next couple of weeks, concerning the voting system.
we'll wait for ppl to issue as many creqs as possible first.

after that we'll see how many animes remain without air/end date and then we'll decide what to do.

BYe!
EXP

[pelican]

Formulating this in SQL is an exercise for the reader, though a simple one.

don't be so sure about that.
you have to keep in mind that performance is always an issue.

I suspect that I could do it in one query if I knew what database you are using and the definitions of the tables. (I _know_ that I could do it in one query if I could modify the tables slightly and add the tiniest bit of overhead to a file change operation. If I could do the same for episode changes, it would be as simple as the current query, at least.)

That was an offer, by the way.

[Skywalka]

Last time I hear anything about it, it was http://www.postgresql.org/

[PetriW]

Formulating this in SQL is an exercise for the reader, though a simple one.

don't be so sure about that.
you have to keep in mind that performance is always an issue.

I suspect that I could do it in one query if I knew what database you are using and the definitions of the tables. (I _know_ that I could do it in one query if I could modify the tables slightly and add the tiniest bit of overhead to a file change operation. If I could do the same for episode changes, it would be as simple as the current query, at least.)
That was an offer, by the way.

I think EXP is competent to do it in one query too... But that it's only one query doesn't mean it doesn't have a performance impact. If he says it'll be too heavy on performance just accept it, he knows what he's doing.

I've heard the same thing said for aom too, people say "omg that's easy and not heavy", well a query that takes 100ms is HEAVY AS HELL but apparently that doesn't occur to people. Just because it's not especially heavy on your mysql with php that has two hits per second doesn't mean it'll be equally not heavy on anidb.
Or queries that "should" be fast that are slow, just because they haven't tested it properly.

(100ms is an example)

*goes back to optimizing the about 1 million sql queries run on a full dump update in AoM*

[pelican]

don't be so sure about that.
you have to keep in mind that performance is always an issue.

I suspect that I could do it in one query if I knew what database you are using and the definitions of the tables. (I _know_ that I could do it in one query if I could modify the tables slightly and add the tiniest bit of overhead to a file change operation. If I could do the same for episode changes, it would be as simple as the current query, at least.)
That was an offer, by the way.

I think EXP is competent to do it in one query too... But that it's only one query doesn't mean it doesn't have a performance impact. If he says it'll be too heavy on performance just accept it, he knows what he's doing.

I did mention that I could do it in another way, and that's guaranteed not to be tough on the db at all.

[PetriW]

I suspect that I could do it in one query if I knew what database you are using and the definitions of the tables. (I _know_ that I could do it in one query if I could modify the tables slightly and add the tiniest bit of overhead to a file change operation. If I could do the same for episode changes, it would be as simple as the current query, at least.)
That was an offer, by the way.

I think EXP is competent to do it in one query too... But that it's only one query doesn't mean it doesn't have a performance impact. If he says it'll be too heavy on performance just accept it, he knows what he's doing.

I did mention that I could do it in another way, and that's guaranteed not to be tough on the db at all.

You also mentioned chaning table layouts and adding overhead though...

[pelican]

I did mention that I could do it in another way, and that's guaranteed not to be tough on the db at all.

You also mentioned chaning table layouts and adding overhead though...

The overheads are only when changing (_really_ changing, not creq'ing) files, though, and they're utterly tiny; insignificant. As for changing the table layouts, that's a fact of life in databases, and it shouldn't be feared. (I'm only talking about adding columns, anyway.)

[egg]

after that we'll see how many animes remain without air/end date and then we'll decide what to do.

Well it has been more than a few weeks. I don't know how many animes still have this issue do not have dates, but I run across them frequently.

The logic does not need to be handled in SQL (although it could be), I believe that all of the information is already loaded for display on the screen on the anime page. Another option would be to have a maintenance program do the logic.

If it is done in SQL or by a maintenance program, then it could be used to display appropriate vote missing flags in mylist... [BTW, I can help with the SQL if you want.]

I think there needs to be a change in the logic though, it needs to be able to handle OLD dates that are not exact. I also reworded it for clarity. As soon as you have a true statement, stop processing rules.

1. If there is no start date or start year, do not allow voting
2. If the is a start date is in the future or the start date is blank and the start year is a present or future year, do not allow voting
3. If the episode count is zero, only allow temporary votes.
4. If the end date is in the past, allow pemanent voting.
5. If the end date is blank year and the end year is a prior year, allow pemanent voting.

I removed the rules that included checking the episodes for the following reasons:
1) Episodes can easily be manipulated (a person could add a bunch of episodes (with various dates) and then vote, where most other changes to allow voting would require a creq).
2) They add to the complexity of the logic with little real value (I am using the year to compensate for older anime that do not have exact dates).

[pelican]

...I can't say that I agree with all of the modifications made here, but at this stage I'm willing to settle for just about anything.

[Rar]

Personally I'm against a lookup check solution here, in favour of a better means of data storage.... I'll go of and bump my solution now.

Rar

[egg]

From [CHANGE][VOTE] Change Perm to Temp for Non-Votable Anime

The problem was that I didn't really agree with that, and that wouldn't help with some of the anime that I have come across.

The presence of a (real, not generic) file for the last episode (as determined by the anime episode count) covers most old anime.

I guess I misread the logic, I yours said that it would not allow it if the episodes did not have release dates (which is also a problem), but I think exp would be more willing to implement something where the files don't need to be checked for each episode. Also the logic to check the files could have problems in some cases where generic files are used as fillers for multiple episode files...

[pelican]

I guess I misread the logic

Yes, you did:

3. If the episode has a release date: voting is allowed if it has passed and disallowed if not.

yours said that it would not allow it if the episodes did not have release dates

Nope; it says that _if_ the last episode has a release date, whether it has passed or not will determine whether voting is allowed or not, respectively. (Unless there is no last episode in the db, as determined by the anime's episode count).

I think exp would be more willing to implement something where the files don't need to be checked for each episode.

I think that it'd be best if I don't express my feelings on what exp is willing to implement in this direction.

Also the logic to check the files could have problems in some cases where generic files are used as fillers for multiple episode files...

How so? I did take generic files into account... oh, unless you mean for double last episodes, in which case a special case is needed.