I want to use numeric IDs in a web application I am developing... However, as the ID is visible to users as a URL, I want to filter out profanity. Things like (I'll leave it to you to figure out what they are):
page.php?id=455
page.php?id=8008135
page.php?id=69
Has anyone solved this? Is this even a real problem?
Does it make sense just to skip numbers in my database sequence?
See also: How can I filter out profanity in base36 IDs?.
How about you using GUIDs? That would encode the actual numbers. I would bet most users don't even notice what is on the url.
Related
I would like to know if it is possible to do a search like this:
"give me all objects where description has more than 1 value"
The short answer is no. At least not from a single LDAP Query without somehow parsing the results.
I know of a tool that will provide those results however it has not been updated in a while but last time I used it, it worked.
I have a table named buildings
each building has zero - n images
I have two solutions
the first one (the classic solution) using two tables:
buildings(id, name, address)
building_images(id, building_id, image_url)
and the second solution using olny one table
buildings(id, name, address, image_urls_csv)
Given I won't need to search by image URL obviously,
I think the second solution (using image_urls_csv column) is easier to use, and no need to create another table just to keep the images, also I will avoid the hassle of multiple queries or joining.
the question is, if I don't really want to filter, search or group by the filed value, can I just make it CSV?
On the one hand, by simply having a column of image_urls_list avoids joins or multiple queries, yes. A single round-trip to the db is always a plus.
On the other hand, you then have a string of urls that you need to parse. What happens when a URL has a comma in it? Oh, I know, you quote it. But now you need a parser that is beyond a simple naive split on commas. And then, three months from now, someone will ask you which buildings share a given image, and you'll go through contortions to handle quotes, not-quotes, and entries that are at the beginning or end of the string (and thus don't have commas on either side). You'll start writing some SQL to handle all this and then say to heck with it all and push it up to your higher-level language to parse each entry and tell if a given image is in there, and find that this is slow, although you'll realise that you can at least look for %<url>% to limit it, ... and now you've spent more time trying to hack around your performance improvement of putting everything into a single entry than you saved by avoiding joins.
A year later, someone will give you a building with so many URLs that it overflows the text limit you put in for that field, breaking the whole thing. Or add some extra fields to each for extra metadata ("last updated", "expires", ...).
So, yes, you absolutely can put in a list of URLs here. And if this is postgres or any other db that has arrays as a first-class field type, that may be okay. But do yourself a favour, and keep them separate. It's a moderate amount of up-front pain, and the long-term gain is probably going to make you very happy you did.
Not
"Given I won't need to search by image URL obviously" is an assumption that you cannot make about a database. Even if you never do end up searching by url, you might add other attributes of building images, such as titles, alt tags, width, height, etc, so you would end up having to serialize all this data in that one column, and then you would not be able to index any of it. Plus, if you serialize it with one language, then you or whoever comes after you using a different language will either have to install some 3rd party library to deserialize your stuff or write their own deserialization function.
The only case that I can think of where you should keep serialized data in a database is when you inherit old software that you don't have time to fix yet.
Apologies, this is kind of a convoluted question. I have a SQL query in a ASP web-page, which is returning a dataset to a webgrid in the page. Looks like so:
Picture of Dataset/Webgrid output in ASP webpage here
I'd like to be able to take the "Community" column and keep the output the same, but make the output into a link to a software client based on the specific Community thats listed. We have a short list of them (maybe 4-5 total) so it'll mean only 4-5 different downloads.
Additionally, I may need to include a field for the OS as we have different downloads per OS (Mac / Windows). I assume if I can get the logic set for one, I can probably repeat that for the other column.
Any ideas on how I could approach this? I'm just not sure how to phrase this question appropriately, but I think this might make it more clear.
Thanks!
what you would need to do is something like
SELECT account, telephone, "<a href='"+communityURL+"'>"+community+"</a>" as CommunityCol, status
FROM myTable
ORDER BY account
... so, assuming the URL is described in communityURL the output you get in the CommunityCol column (from memory you might need to rename it) is a concatenated string containing what you need
Can anyone tell me why this works:
https://graph.facebook.com/fql
?q=SELECT display_name FROM application WHERE app_id=0&access_token=...
(and returns 0 results, obviously)
but this doesn't:
https://graph.facebook.com/fql
?q=SELECT display_name FROM application WHERE app_id>=0&access_token=...
(HTTP 500)
The FQL pages on Facebook itself only ever give the simplest of queries - they never give samples of more complex queries involving strpos() and anything other than =.
I am aware of the need to work on an indexed column, but app_id is definitely one of those :)
If the column is indexable you still need to provide specific values for it.
If you could provide vague ranges (e.g. '>0') it would defeat the restriction of requiring you to specify the target objects first, and filter later
What drawbacks can you think of if I design my REST API with query strings without parameter values? Like so:
http://host/path/to/page?edit
http://host/path/to/page?delete
http://host/path/to/page/+commentId?reply
Instead of e.g.:
http://host/api/edit?page=path/to/page
http://host/api/delete?page=path/to/page
http://host/api/reply?page=path/to/page&comment=commentId
( Edit: Any page-X?edit and page-X?delete links would trigger GET requests but wouldn't actually edit or delete the page. Instead, they show a page with a <form>, in which page-X can be edited, or a <form> with a Really delete page-X? confiramtion dialog. The actual edit/delete requests would be POST or DELETE requests. In the same manner as host/api/edit?page=path/to/page shows a page with an edit <form>. /Edit. )
Pleace note that ?action is not how query strings are usually formatted. Instead, they are usually formated like so: ?key=value;key2=v2;key3=v3
Moreover, sometimes I'd use URLs like this one:
http://host/path/to/page?delete;user=spammer
That is, I'd include a query string parameter with no value (delete) and one parameter with a value (user=spammer) (in order to delete all comments posted by the spammer)
My Web framework copes fine with query strings like ?reply. So I suppose that what I'm mostly wondering about, is can you think of any client side issues? Or any problems, should I decide to use another Web framework? (Do you know if the frameworks you use provides information on query strings without parameter values?)
(My understanding from reading http://labs.apache.org/webarch/uri/rfc/rfc3986.html is that the query string format I use is just fine, but what does that matter to all clients and server frameworks everywhere.)
(I currently use the Lift-Web framework. I've tested Play Framework too and it was possible to get hold of the value-less query strings parameters, so both Play and Lift-Web seems okay from my point of view.)
Here is a related question about query strings with no values. However, it deals with ASP.NET functions returning null in some cases: Access Query string parameters with no values in ASP.NET
Kind regards, Kaj-Magnus
Query parameters without value are no problem, but putting actions into the URI, in particular destructive ones, is.
Are you seriously thinking about "restful" design, and having a GET be a destructive action?