Still moving along with the duplicate entries idea, I have created two master swords (which would be awesome if I could do that in real life) and I can do identical games as well. This probably isn't much of an issue, but I'll say it anyway.
Adding a donation without saving donor info still wipes it. I'm sure you're aware of that since it didn't sound like you knew how you were going to fix it.
When adding a bid, the search button returns challenges for all games instead of just the one you chose in the speedrun field. Search button returns an error "incompatible data type in operation" if you have the check mark on Speed Run so I'm not really sure what that check mark is for. You also can't attach a bid before you save the donation amount which probably just means you need to remember to save it first.
Still moving along with the duplicate entries idea, I have created two master swords (which would be awesome if I could do that in real life) and I can do identical games as well. This probably isn't much of an issue, but I'll say it anyway.
Are you using the HSQLDB file database? If so, then this is an issue with the schema generation that I'm using. Its been a bit flaky, but that issue doesn't come up using a properly configured MySQL database.
Quote from dballin:
Adding a donation without saving donor info still wipes it. I'm sure you're aware of that since it didn't sound like you knew how you were going to fix it.
That's kinda super low priority atm. When in doubt, save (n.b. you can press ctrl-S to save on almost any tab).
Quote from dballin:
When adding a bid, the search button returns challenges for all games instead of just the one you chose in the speedrun field.
Quote from dballin:
Search button returns an error "incompatible data type in operation" if you have the check mark on Speed Run so I'm not really sure what that check mark is for.
Again, that's only coming up in the HSQLBD implementation. I'll be honest, I really haven't been testing anything on the HSQLDB side, just because its really not going to be used, at least for now. I'll try taking a look at those issues, but I can't make any guarantees, which sucks because its really helpful for testing on boxes that don't have MySQL installed.
*EDIT*AHAHA that was the funniest bug I've ever fixed. K, this will work once I push the next update. I'll see about getting the constraints to work properly in HSQLDB first though*/EDIT*
Note that it is working correctly when the box isn't checked: it ignores whatever's in the field when its not checked. I'm actually thinking of also visually disabling the associated field/button when its unchecked just to make it more clear, but that's also really low priority.
Quote from dballin:
You also can't attach a bid before you save the donation amount which probably just means you need to remember to save it first.
That's by design. In general, this won't be an issue since chipin donations' amount is pre-set and can't be changed, and the VAST majority of the donations will be chipin donations. Again, when in doubt, save.
hsqldb Memory is the one I've been using. I haven't actually saved a db and loaded it. As far as saving, yeah. I just wanted to try things out to see what would happen if somebody (like me) had no idea what they were doing and skipped a step by accident. Saving often will need to be beaten into people's heads I suppose.
lol, I could try doing what most IDEs do and put an asterisk or some kind of a marker on the current tab every time you make a modification to the document, then remove it after you save or refresh. It helps me remember to save constantly.
Anyways, I'm still trying to the constraint generation to work: I think I know how to go about it, but there is some weirdness that's preventing me from implementing it properly. Worst-case, you'll get the very unfriendly error messages in the HSQL version since I won't be able to detect which constraint got violated.
Oh, I just remembered, did you ever fix the issue where a name such as "A D Kelf" on chipin would be interpreted as "D, A"? Actually, not sure HOW that should get interpreted now that I think about it...
Oh, I just remembered, did you ever fix the issue where a name such as "A D Kelf" on chipin would be interpreted as "D, A"? Actually, not sure HOW that should get interpreted now that I think about it...
Nope. I'm almost considering just collapsing the first/last name into just 'name', but that's a lot of work...for you! You'd have to do updating the schema and your website. It'd be pretty straightforward for me.
Alternatively, I was thinking just using a consistent scheme for making the first token the first name, and then the rest last name.
I think the other way around might be better, having the last token be the last name and everything else be first. I'm not sure which is more likely to be wrong.
Also, collapsing everything into one name would completely break the privacy filter and the page sorting, so don't do that.
I give up on setting the HSQL db constraints, its just not working and I'm too tired to care. I'm just going to make do the thing with the search fields and call it a night
edit: pushed changes, but there's nothing majorly different.
edit2: - Script running is working again. - I at least got some of the constraints working again in HSQLDB, just no good error messages to go along with them
Edit 3:
Quote from Rakuen:
1) Might be good to support a reverse lookup for bids.
- Done, though not extensively tested yet.
Also, I'm running out of ideas to implement, any requests anyone?
Also, I'm running out of ideas to implement, any requests anyone?
Cross-posting from prizes: this has been proposed as a different way of doing prize drawings for particularly awesome prizes of awesome (such as the master sword). Could you implement that?
Certainly doable (I'm assuming you're referring to the raffle version), and it shouldn't be too hard. Just to be absolutely clear:
- There is a minimum entry cut-off of X dollars, where X is specified by the user - If Y dollars is the sum contributions of a given donor D within a user specified time period (which can be infinite in either direction for things like grand prizes and such), then that donor is floor(Y / X) times more likely to win than a donor who contributed exactly X dollars.
EDIT: Do you want me to implement any other forms of prize drawing, like higest-single donation in a time period, highest sum donations in a time period, etc?
Well that's not how I'd have expressed it (guess that's why I'm not a programmer, heh...) but yes, that's the gist of it.
I don't think highest single donation would be necessary (even if we did do any incentives that way, one could simply manually check that without too much trouble) but the latter would definitely be useful for the Iji donation incentive. I can't think of any other methods that would differ from those we already have in any way off hand.
Had a thought while looking at the prize list: Maybe the minimum bid and start/end games could be actual database entries and not just put in the description. Kinda low priority, but might be useful.
Those attributes are true for every prize entry, so I say go for it if/when you have time. Having them in separate columns would make the tracker data a bit cleaner and easier to read too (I had to truncate a bunch of game names to keep the Description column from word wrapping too much).
Unless I'm doing something wrong, the prize search doesn't seem to be working (the below search should return the dungeon man perler, and I've tried other strings too with the same outcome).