Perverse my ass. They added innerHTML because it was far easier (and in some cases faster) than the DOM equivalent. document.all adds nothing except IE dependance.
As for needing document.all, you can add it yourself to point to the resources you need. Mozilla's JavaScript object model is quite flexible.
Personally, I haven't missed document.all. I could see where you might need it for maintenance of existing scripts, but I would categorize it as perverse.
Now, IE 6's behavior in fixing the box model broken in IE 5.x but not allowing the CSS2 selectors so all of the existing CSS pages break: that's perverse.
Then again, not as perverse as iCabs support for CSS2 selectors but complete brainfuck with regard to CSS rendering implementation.
There's plenty of perversion in web browsers. Why pick on Mozilla's ommision of document.all?
IE 6 supports W3C standards quite well. Mozilla does it better, but IE 6 is close enough to get most things done. IE 5.0-5.5 aren't that bad in CSS either. They have their issues but they are a damn sight better than Netscape 4.
First off, the browser stats vary dramatically by site. The stats I've been seeing lately have IE 6 ahead of 5.x (probably due to sales of computers with XP, Windows Update, and the gentle nudging toward v6 because of its standards support).
If you code a page for the quirks of IE 5.x and tweak from there, you are coding for the past. It's quite clear that browsers are moving toward W3C standards support, not away from it. If you code toward the standards and tweak from there, you are much more likely to build a site that will stand the test of time and not break in newer browsers.
As for availablity, if you code for valid XHTML, CSS, and WAI (accessibility) guidelines, older clients tend to degrade gracefully. Using "tricks" like specifying media="all" in stylesheet link tags or using @import makes it easy to code to modern browsers but make the content available to older browsers (like Netscape 4).
XHTML+CSS with no tables and proper stylesheet declarations can make for beautiful sites that are both accessible to those with disabilities and browsers all the way back to Netscape 1.x.
It requires that you give up on making Netscape 4 and IE 4 pretty though. But it sounds like you've done that already.
Newer versions of Mozilla (and Netscape 7 I think as well) added support for document.all for script compatibility. That said, it's better to use the standard DOM methods as IE 5+ support most of them just fine.
Netscape 4 (and other obsolete browsers) still get the content, but you are free to move on and use modern layout techniques for better browsers.
The use of @import in your CSS file is another good method to prevent bad browsers from doing stupid things.
Don't want the page to look like it was made in 1995? Upgrade your browser. Don't care if the page looks like it was made in 1995? Keep using Netscape 4.
Aside from the fact that I was chagrined to find that my copy of Mozilla supports the marquee tag (formerly an IE-only tag), it's all fairly predictable; HTML isn't really a problem.
The issues with browser compatibility are found in support for the DOM and (even more so) CSS. They have all supported table tags for years and the incompatibilities there are minor. What I really want are browsers that render the box model correctly, don't freak out when you use floats, and have sane implementations of "left," "right," margins, and padding.
According to this table, DHTML is supported by IE 4.0 and up. That's actually pretty useless. What is their metric? That you can add an element programmatically?
DHTML is the fusion of DOM, scripting, and CSS. But it doesn't cover how complete the DOM support is (eg. does it support mutation events?), how powerful the scripting support is (eg. are regexes supported in their version of ECMAScript?), or how standards compliant the CSS is (eg. is the box model and float handled correctly?).
You bring up an interesting point. Although I must tell you that there is already caching done within the hard drive already (not at the head level though;-)), transactions are indeed an issue with drives. Drives will commonly tell an operating system that it's done writing when the data is still in the cache and not yet on the platter. People have been grappling with the problem of speed vs. data integrity.
Re: separating functionality I do separate functionality. My logic layer and my presentation layer (they are separate for you too right?) can make checks for data validity as well. In fact, I recommend it. It hurts far less to check a value twice than to forget to check it even once.
Ummm...when did I say anything about country lists and sales prices? Think carefully. Check my post. I talk about data: the cleanliness of that data, the integrity of that data, the status of that data, etc. I never talk about doing advanced logic. Then again, why wouldn't you save a list of countries (and the most up to date info on exchange rates) in the database? Or were you talking about user interface translations (which I wasn't). Why wouldn't you have sale prices for items sold during sales? You would keep that info wouldn't you? You would want to know that the item sold for $12 instead of $18 wouldn't you?
Side note for those who didn't get the memo yet: database transactions != financial transactions. Database transactions can be used to facilitate financial transactions, but they are not and have never been the same.
My user interface *is* separate from my persistence layer. Dear god man! Is your user interface really that simplistic?
I'll tell you what. I'll give you a code snippet and see what you think about it.
CREATE TABLE "lusers" (
"id" serial NOT NULL,
"username" character varying(32) NOT NULL CHECK (length(trim("username")) > 2),
"password" character(34) NOT NULL CHECK (length(trim("password")) = 34),
Constraint "luser_pkey" Primary Key ("id") );
CREATE OR REPLACE FUNCTION set_password() RETURNS opaque AS
'DECLARE
clear_password text;
BEGIN
clear_password:= trim(NEW."password");
IF length(clear_password) < 6 THEN
RAISE EXCEPTION ''Password must be at least six characters'';
END IF;
NEW.password:= crypt(clear_password,gen_salt(''md5''));
RETURN NEW;
END;' LANGUAGE 'plpgsql';
CREATE TRIGGER "lusers_password_trigger"
BEFORE INSERT OR UPDATE ON "lusers"
FOR EACH ROW EXECUTE PROCEDURE set_password();
Hmmm...at first glance, this may seem like a lot of logic to have in your database, but look closer. If someone tries to put in a password less than six characters, it fails. Clients do not have to learn how to use MD5 or how much padding is used in all implementations. This means that anyone, in any applicable query, with any client -- and is authorized to make changes to the database -- who makes an INSERT or UPDATE on the users table will have constraints put upon them. Once you get at least five developers together on a project, the methods for talking to the persistence layer will drift -- perhaps just slightly, but it will drift.
And now hear this: nothing is stopping you from making additional application checks at the client level for data integrity. In fact, it makes sense so that you don't have to make the persistence roundtrip. However, you should not overlook the fact that you cannot put a bad value into my database schema. The database simply won't accept it (I still need to make dictionary checks, but time is short).
But do you see the difference? This isn't about antiquated storage methods (punch cards). This is the difference between your method which shouldn't have bad data if written correctly and my method which absolutely doesn't allow bad data in the database. Period.
There's a difference between being relatively sure that the data in your database is valid and knowing for sure that the data is valid (Yes, yes, I know: backups in case of hardware failures).
The data is the database's responsibility. Moving data here and there, communicating with the user, and all sorts of other logic details are the app layer's responsibility. Here, the database is just making sure the data is clean. That's all. In my earlier example, the database was setting up a timestamp value for caches. The timestamp is data. The timestamp refers to validity of other data. This can go in the database itself. It's not really anyone else's business.
This should be the app layer's responsibility? I have only these counterexamples. SELECT MAX(lastmod) when there are no triggers and functions (see my previous post). Making sure the MD5 implementation is the same for all client libraries in all languages when there are no triggers and functions.
No code is perfect. I'm not advocating that you rely solely on the database. What I'm saying is that the database can be correctly used as a last line of defense for bad data that somehow crept through.
is perfectly permissible. The following compiles and runs fine. Go ahead, try it. I'm not saying it's good coding style, but would you argue that all coders demonstrate good coding style?
#include <stdio.h> #define char int
int main () {
char hello = 387;
printf("%d\n", hello); }
Anyone using the wrapper can be guarenteed that contraints will be enforced, etc. Also, things like foreign key contraints are handle automatically or subclassed for tricky relationships.
In addition, I hate seeing error messages come back from the db. If I can handle all the errors client side, clean data is the *only* thing that gets submitted. I know it's not the accepted way of doing things, but it works very well.
Every other database has the philosophy that bad data is not allowed. Period. What happens when you leave your company -- or you're on vacation -- and the new guy who is familiar with MySQL just decides to whip up a script to perform some query on the database?
I'm not trying to say that what you have doesn't work for you. I'm saying that what you have is vulnerable to circumvention without malice.
As a side note, your engine sounds conspicuously like EJBs and the.Net framework. Does anyone but you know how to use this persistence layer? Is it distributable?
In addition, I hate seeing error messages come back from the db. If I can handle all the errors client side, clean data is the *only* thing that gets submitted. I know it's not the accepted way of doing things, but it works very well.
Ummm...so? Java can catch SQL Exceptions, C can check error codes, Perl can trap any error message with eval. If you are seeing messages from the database when you didn't intend to, you have done something wrong. Don't blame the database engine. This is an app layer bug.
In other news, I raise exceptions in stored procedures all of the time. Those error messages are clear, concise English phrases that I specify.
For example, I have this statement in one of those stored procedures called from an insert and update trigger:
RAISE EXCEPTION "The password must be at least six characters!"
Seems to me like a friendly and useful database error message to me.
Another benefit of what I'm doing allows me to quickly port my apps to other databases. Once the layer for Postgres is created in the compiler, I just recompile on the schema, and boom...
This is a good thing, but it doesn't justify the use of MySQL; It only justifies the use of your object layer. If you took out MySQL support, you could have triggers, stored procedures, views, advanced constraints, custom data types, rules, etc. when you moved from database to database. Why limit your options with MySQL? If it's so that you can support everything, do you also support comma-separated-value files through ODBC as well, or would that be silly? There is always a lower level of functionality.
Just as you wouldn't waste your time with CSV over ODBC because of limited functionality and brittleness, why do you waste your time with MySQL?
Is MySQL faster for SELECTs? Sure. But what people don't seem to get is that with all of those "useless" features of real RDBMSs, you can make a schema that enforces correct data (reducing processing time and complexity in the app layer), and you can have triggers and rules modify cache tables that give commonly used data and/or last-modified info. I don't care how fast MySQL has been or wil be; The fastest queries will always be the ones that you don't have to make as many times. The best use of a database is usually where you don't have to send as much data over the wire in communication.
Example: You have dynamic content, but the interval between updates is large enough to justify caching.
Using MySQL, you would have to insert the data with a timestamp (don't forget the index on the column!), make a query for the newest timestamp using a MAX aggregate, check the timestamp against the cache timestamp, make the real query if the timestamp's newer than cache, get the results back, and update the cache timestamp. Note that you would have to remember to update an entry's timestamp in every part of the code that would ever make updates the table(s). And of course, this is only a single table for granularity. For joins, you would have to do multiple max timestamp checks.
With the others, you would make a cache table with just one timestamp entry for the query -- no matter how many tables it spanned. Note that you have already saved rows*sizeof(timestamp)*tables in space over MySQL as a bonus, so your tables are more likely to fit into physical RAM for greater performance. Next you would write an insert and update trigger for the tables that would update this cache timestamp value on changes. The logic for this is located in only one place: the source of the data.
Using a database other than MySQL, you would insert the data without a timestamp (handled internally by the database), SELECT on the very small cache table for one entry, compare against your local cache timestamp, make the real query if the timestamp's newer than cache, get the results back, and update your app cache.
I don't care how fast you think MySQL is. It will never be able to make repeated "SELECT MAX(modified) FROM bigtable;" calls faster than repeated "SELECT modified FROM cache WHERE key = 'somedatamodel';" The overhead of updating a single or small number of rows to change a timestamp value is lost in the overall insert or update processing (no index and it's update overhead is necessary for that small a table). And any client, custom object model or no, will work.
THIS is why I have a problem with MySQL. It isn't some esoteric feature. I want to scale. No database benchmark will adequately demonstrate this when all it is comparing is SELECT and INSERT performance. I want to set up my database and go -- not constantly tweak my app layer to fudge a few milliseconds of processing time less or sacrifice data dynamism. It's not that the other databases are more feature-rich; MySQL is feature-poor. Will it work for small installations? Sure, but so will any other database out there. The small problems are easy. It's the big problems -- or the small problems that steadily grow -- that demand our attention.
If you want to use it, that's your decision. But don't delude yourself or others into thinking it is the optimum solution.
No, because according to the rules of English, you shouldn't. According to those same rules of English, book titles are italicized or, in the case of handwriting, underlined.
I use italics for parenthetical meterial (
like this) as a side-note, or for extra contextual material.
You are among a small minority. Parentheses are commonly used for asides that do not fit within the context of the associated sentence.
Besides, if you were to do this in plain text (which all html should downgrade gracefully to), quotes are the common way to denote a book name.
_Book Name_ is more common in practice. This is one of the many areas where plain text is deficient over a document with structured formatting.
If you really want to split hairs, you shouldn't have used parentheses in your last sentence as the parenthetical material is closely associated with the content of the enclosing sentence. As a comma is too soft a break in the flow of the sentence, it would have worked better with an mdash.
"Besides, if you were to do this in plain text -- to which all html should downgrade gracefully -- quotes are the common way to denote a book name."
I realize that two hyphens are not technically an mdash, but at least it holds some semblance of correctness. Think of English as a complex programming language and the reader as a compiler or runtime environment. The more strict the input, the faster it gets processed.
Your use of italics in parentheses and quotes around book titles is akin to errant C macros that redefine core functionality. It obfuscates. You are, of course, entitled to your own writing style, but don't presume that it's correct or encourage others to adopt the practice.
Just because people are largely ignorant of the rules of English does not mean that those rules do not exist. It's a crying shame that grammar isn't taught in most U.S. public schools anymore.
FYI: I studied literature in college; however, I thought that an analogy to programming would go over better in this forum.
Don't forget "secure." C allows no protection from buffer overflows and other sundry security holes. Is it possible to code safely in C? Sure, but 99% of all existing C coders cannot.
An IMAP server is an example of a widely available network service. Even if the IMAP server is slower because it was written in Python, you have a dramatically lower chance of opening up a remote root exploit.
It all falls on where your priorities lie. I'd say that programmers these days should err on the side of safety for the sake of their users and not on squeezing the last bit of speed out of an implementation detail (choice of language).
Indeed I was paying attention. And you've never kissed someone with your eyes open? How old are you? Twelve?
Fine. Let's say I missed this subtle eyeball powerplay. This cunning conquerer of millions of worlds was ultimately tricked by one android. The most efficient method to conquest, apparently, was to seduce Data and coerce his actions.
Sure, he "encrypted" the computer's databank. Tell me, do you think today's codebreakers would have a problem with anything devised in the fifties? Now realize that the Borg are more than fifty years ahead of the Federation in technology -- they've assimilated all of the cryptographic techniques of millions of worlds!
But okay...let's assume that she can't decrypt it. She's under time pressures and all. After Data decrypted the computer, what efficiency reason is there to rely on him for anything ever again? It would've been more efficient for the queen to destroy the warp test vessel herself.
And what part of efficiency justifies her fixation on Picard? What possible purpose did it serve? He doesn't want to be her boy toy? Fine. Assimilate him and send him to the drone mines. But no, she went on a whole, "I've got a new man and he's better than you were anyway." Uh hunh. Talk about petty. Oh wait! Pettiness is tied to emotions. I guess she let her emotions mislead her after all.
"...only so much of their linear behaviour you can take."
Funny. That linear, rigid, unerring behavior is precisely why the Borg became Trek's favorite villain. Everything they did in First Contact made the Borg less intimidating and weaker. Give me linear behavior any day!
The primary point to the Borg was that there was no individuality -- no personality. Then they manufactured individuality and personality into the Borg at a basic level. Don't get me started on that "Unimatrix 0" crap in Voyager.
When the first cube came into Federation space, it completely demolished basically the entire fleet. Now this time, Picard knows the weakness that allows it to be destroyed no problem. Funny, I thought the whole point to the cubes was that there was no central weak point. Everything was redundant -- including the crew. THAT was scary. A systemic command to sleep was the only thing that saved them on that first encounter. Now they just aim for the weak spots. Nice. After millions of worlds, only the Federation seems to find these weak spots.
Don't you read your own links? What part of "InnoDB Hot Backup is a non-free additional tool which is not included in the standard MySQL distribution" is unclear to you?
He didn't say it didn't exist. He said that it costs money and doesn't come with the main distribution.
Don't know what to tell you there. I know foreign key support is planned, but I'm handling all my data integrity inside my apps.
Precisely where it shouldn't need to be. You should be able to make a database schema, populate it with data, and know that your data is safe and consistent. Any bad db admin can muck up a schema, but MySQL prevents the good DB admins from doing their job properly.
It is rare that any non-trivial application has only one developer or cohesive group. Database schemas are usually designed by a single person or core group. Can you assert that everyone you work with will clean the user input correctly or work delete a record that another record depends upon? If you design your schema correctly, the DELETE either fails or deletes all of the records that relate to it depending on what data model you choose. An INSERT, UPDATE, and DROP is similarly constrained -- and all or nothing affair with no ambiguities in between.
Your app code can have some checks. Too many checks never hurts quite as much as too few. With PostgreSQL, SAP DB, Oracle, MS SQL, Sybase, DB2, etc., the database is a valid last line of defense against invalid data. They can be made to NOT ALLOW bad data to enter or become bad after it's in. This is the default behavior and not a special set of tables you choose when you download the "Max" version.
If your data is important enough to store, it's important enough to protect. If integrity doesn't matter as much, if your data isn't that important, just use a flat file -- it's much faster for reads and caches well. Or you could put SQUID in front of your web app in which case the database needs to be just fast enough...
Now then, a question: Does MySQL have support for cell constraints like limiting an integer field to a value between 15 and 90 or making sure that a text field has at least seven characters or matches a valid social security number? This is not flamebait; I don't know, and I'm curious. I don't see mention of them on a search of "constraint" on the mysql.com. I certainly hope it does or I'll have a new thing to bitch about with MySQL.
You're kidding right? This was noticeably better than Star Trek 4? It wasn't even good!
What about the Borg scared the crap out of us when we first saw them? The hive mind. The collective. The lack of individual thought. The elimination of self...utterly. It was worse than servitude or slavery. It was the complete annihilation of everything you are, were, and ever would be. You are a number.
Then they introduce a "queen." The Borg isn't a hive mind anymore; It's an extension of the queen. Well then, just kill the queen (like in Voyager...ugh). I can't believe anyone is forgiving the script writers for things like Picard "forgot" about the queen and her wanting someone at her "side." Yeah, because with the chorus in her head, she's lonely. Yeah, after millions of worlds, now she could use some help. Yeah, after millions of worlds, she needs *Picard's* help.
The Borg became too...human. What would the Borg of the series have done when in contact with Data? Ohh! Neat technology. *sucking sound*
But no! In First Contact, the Borg sprouts a queen, she gets her nipples hard over Data, and allows her emotions (!!!) to mislead her. She was actually bitter because she lost Picard! She apparently is responsible for the cultural vacuuming of trillions of beings, but somehow Picard and Data were "special."
This is the Borg!! Why would they need love, companionship, reproduction, or sex? If they wanted to feel good, they can just flip a switch and have a collective orgasm.
But yeah, some dialog about Moby Dick and Troi getting drunk definitely made up for it. Puhleese!
Didn't anyone else notice that the movie neutered Star Trek's best adversary? I feel like I'm taking crazy pills!
The main problems with it versus broader garbage collection schemes are circular references and overhead.
If two (or more) objects have a reference to one another, the count can never reach zero even if nothing in the main logic points to those objects anymore.
Also, every time an object gains or loses a reference, a check for a count of zero is made. In fuller garbage collection setups, periodic checks are made to all of the objects in a low-priority thread. In some cases, memory usage can be higher, but performance is also higher sometimes and it can handle circular references.
Both are better than repeated use of malloc/free and new/delete though.
--
C also muddies this concept because there are no objects in C.
in that folks who use C can avoid common pitfalls. But so much of this seems like it has been tackled by C++. Only C++ did it cleaner. C++ is complex though. So this only leaves (horrors) a higher level language that removes all of these implementation details that lead to insecure programs.
Do it in a higher-level language first. Make sure your algorithms are clean and efficient. If and only if you see a performance or resource problem do you rework portions(!!!) in C. As a bonus, the higher level language acts as a code template for faster C development.
Once you are at that point, this Mini-HOWTO will definitely be a great resource to use.
If you're willing to hang someone upside-down from their toenails, would you really care about the license terms of some software?
Their hearts are the right place, but c'mon! Let's say Amnesty International comes forward saying that Regime X violates human rights. Then you find out that Regime X is using your software. Do you believe that Regime X, torturer of thousands, gives a rats ass about some programmer's licence terms?
Do you think that your government is going to say, "Well sure, they sodomize children in the factories, but let's try economic sanctions because of their software license violations."
-----
On a side note, the U.S. is routinely criticized for the continued use of the death penalty, the living conditions of prisoners, domestic spying, imprisonment without due process, and other sundry items. Since the U.S. is a democratic republic, does that mean that everyone in the U.S. is forbidden the use of this software due to their complicity in human rights violations?
Well if you are not experienced enough to make the difference between two table handlers, then you obviously won't be any more capable of using BEGIN/COMMIT/ROLLBACK correctly.
You're absolutely right about using BEGIN/COMMIT/ROLLBACK. However, simple UPDATE statements also use transactions without that syntax. All statements are protected and atomic in PostgreSQL. You only need BEGIN/COMMIT/ROLLBACK for a group of statements. A newbie who doesn't fully understand ACID can still take advantage of the protections afforded by ACID.
As for MySQL, how does he know when to use InnoDB versus MyISAM, BDB, HEAP, MERGE, etc.? My point was that in other databases, the default behavior is to protect the data. You should have to choose speed, not safety. If InnoDB was the default, while I would still have reservations about MySQL, it would allay many of my concerns regarding its general use by newbies.
Once again and with feeling, "Joe Newbie doesn't automatically need to use every feature of PostgreSQL." Just as beginning programmers don't need to know how to do memory mapping, you don't need to write triggers. But if they ever need to use memory mapping, isn't it nice to know that it's there?
*** As a side note, transactions took me less time to figure out than SELECT, INSERT, UPDATE, and DELETE. Views took me two minutes. Triggers and rules took a little bit longer. I worry about folks who say that PostgreSQL is too complex to figure out. Intelligent database design takes much longer to figure out than query semantics. This "simpler" mantra from the MySQL camp sounds like a red herring these days.
If all you need is CREATE TABLE, INSERT, UPDATE, SELECT, and DELETE, then just use those constructs. Nobody's holding a gun to your head forcing you to use stored procedures. But if a problem comes up down the line that is perfect for a view, why not use it? The only reason I can see not to is if you are saddled with MySQL.
That's absolutely wrong. Plenty of applications don't care about protecting what they store : caching systems, Web stats, etc.
The data may not be relied upon for extended periods of time, but its integrity is still important.
You don't care about errors in your web statistics? Why gather them in the first place then? I'm not talking about storing last week's stats; I'm talking about using this week's.
The best case scenario for an invalid cache entry is that the app ignores it. The worst case is that bad data is used. This is not acceptable. If the data is unreliable, why are you using it? Why not pull from/dev/random? Is it because the data has some coherent meaning? If so, it's worth protecting.
If *you* decide to discard the data after a few seconds, that's your prerogative. But it should always (always!) be your decision as a user of programmer -- not the result of a data integrity issue.
Non-determinism is the harbinger of a little mind.
You are indeed correct. I mistyped. With updates like in my example, you don't have to explicitly lock a table. Strictly speaking, you don't have to in MySQL either; you just do it with some risk to your data.
In the next versions of PostgreSQL, support for nested transactions would solve those particular problems. But as that's a feature not yet available, I cede the point.
No, MySQL *can* be ACID-compliant. It is not by default. A new user would not necessarily know that they have to use an "atomic" or "transaction" table. MySQL is supposedly newbie-friendly. Yet they must determine advantages of MyISAM over InnoDB over plain tables. For a newbie user of PostgreSQL, they can just create a table and be done with it.
I disagree that ACID can ever be optional. Once again, if it's important enough to store, it's important enough to protect.
Slashdot Mirror
Perverse my ass. They added innerHTML because it was far easier (and in some cases faster) than the DOM equivalent. document.all adds nothing except IE dependance.
As for needing document.all, you can add it yourself to point to the resources you need. Mozilla's JavaScript object model is quite flexible.
Personally, I haven't missed document.all. I could see where you might need it for maintenance of existing scripts, but I would categorize it as perverse.
Now, IE 6's behavior in fixing the box model broken in IE 5.x but not allowing the CSS2 selectors so all of the existing CSS pages break: that's perverse.
Then again, not as perverse as iCabs support for CSS2 selectors but complete brainfuck with regard to CSS rendering implementation.
There's plenty of perversion in web browsers. Why pick on Mozilla's ommision of document.all?
Sorry about that...I was remembering discussion about this incorrectly. I stand corrected.
IE 6 supports W3C standards quite well. Mozilla does it better, but IE 6 is close enough to get most things done. IE 5.0-5.5 aren't that bad in CSS either. They have their issues but they are a damn sight better than Netscape 4.
First off, the browser stats vary dramatically by site. The stats I've been seeing lately have IE 6 ahead of 5.x (probably due to sales of computers with XP, Windows Update, and the gentle nudging toward v6 because of its standards support).
If you code a page for the quirks of IE 5.x and tweak from there, you are coding for the past. It's quite clear that browsers are moving toward W3C standards support, not away from it. If you code toward the standards and tweak from there, you are much more likely to build a site that will stand the test of time and not break in newer browsers.
As for availablity, if you code for valid XHTML, CSS, and WAI (accessibility) guidelines, older clients tend to degrade gracefully. Using "tricks" like specifying media="all" in stylesheet link tags or using @import makes it easy to code to modern browsers but make the content available to older browsers (like Netscape 4).
XHTML+CSS with no tables and proper stylesheet declarations can make for beautiful sites that are both accessible to those with disabilities and browsers all the way back to Netscape 1.x.
It requires that you give up on making Netscape 4 and IE 4 pretty though. But it sounds like you've done that already.
Newer versions of Mozilla (and Netscape 7 I think as well) added support for document.all for script compatibility. That said, it's better to use the standard DOM methods as IE 5+ support most of them just fine.
The same story with the "innerHTML" property.
Netscape 4 is a pile of crap. Just use the following in your pages.
<link rel="stylesheet" type="text/css" href="thecssdeclarations.css" media="all"/>
Netscape 4 (and other obsolete browsers) still get the content, but you are free to move on and use modern layout techniques for better browsers.
The use of @import in your CSS file is another good method to prevent bad browsers from doing stupid things.
Don't want the page to look like it was made in 1995? Upgrade your browser. Don't care if the page looks like it was made in 1995? Keep using Netscape 4.
Simple.
While I still believe that HTML is a minor issue these days, the hobgoblins and headaches are with CSS.
:(
CSS Property Support
CSS Selector Support
It doesn't cover how well each feature is supported though.
Aside from the fact that I was chagrined to find that my copy of Mozilla supports the marquee tag (formerly an IE-only tag), it's all fairly predictable; HTML isn't really a problem.
The issues with browser compatibility are found in support for the DOM and (even more so) CSS. They have all supported table tags for years and the incompatibilities there are minor. What I really want are browsers that render the box model correctly, don't freak out when you use floats, and have sane implementations of "left," "right," margins, and padding.
According to this table, DHTML is supported by IE 4.0 and up. That's actually pretty useless. What is their metric? That you can add an element programmatically?
DHTML is the fusion of DOM, scripting, and CSS. But it doesn't cover how complete the DOM support is (eg. does it support mutation events?), how powerful the scripting support is (eg. are regexes supported in their version of ECMAScript?), or how standards compliant the CSS is (eg. is the box model and float handled correctly?).
You bring up an interesting point. Although I must tell you that there is already caching done within the hard drive already (not at the head level though ;-)), transactions are indeed an issue with drives. Drives will commonly tell an operating system that it's done writing when the data is still in the cache and not yet on the platter. People have been grappling with the problem of speed vs. data integrity.
Re: separating functionality
I do separate functionality. My logic layer and my presentation layer (they are separate for you too right?) can make checks for data validity as well. In fact, I recommend it. It hurts far less to check a value twice than to forget to check it even once.
Ummm...when did I say anything about country lists and sales prices? Think carefully. Check my post. I talk about data: the cleanliness of that data, the integrity of that data, the status of that data, etc. I never talk about doing advanced logic. Then again, why wouldn't you save a list of countries (and the most up to date info on exchange rates) in the database? Or were you talking about user interface translations (which I wasn't). Why wouldn't you have sale prices for items sold during sales? You would keep that info wouldn't you? You would want to know that the item sold for $12 instead of $18 wouldn't you?
Side note for those who didn't get the memo yet: database transactions != financial transactions. Database transactions can be used to facilitate financial transactions, but they are not and have never been the same.
I'll tell you what. I'll give you a code snippet and see what you think about it.Hmmm...at first glance, this may seem like a lot of logic to have in your database, but look closer. If someone tries to put in a password less than six characters, it fails. Clients do not have to learn how to use MD5 or how much padding is used in all implementations. This means that anyone, in any applicable query, with any client -- and is authorized to make changes to the database -- who makes an INSERT or UPDATE on the users table will have constraints put upon them. Once you get at least five developers together on a project, the methods for talking to the persistence layer will drift -- perhaps just slightly, but it will drift.
And now hear this: nothing is stopping you from making additional application checks at the client level for data integrity. In fact, it makes sense so that you don't have to make the persistence roundtrip. However, you should not overlook the fact that you cannot put a bad value into my database schema. The database simply won't accept it (I still need to make dictionary checks, but time is short).
But do you see the difference? This isn't about antiquated storage methods (punch cards). This is the difference between your method which shouldn't have bad data if written correctly and my method which absolutely doesn't allow bad data in the database. Period.
There's a difference between being relatively sure that the data in your database is valid and knowing for sure that the data is valid (Yes, yes, I know: backups in case of hardware failures).
The data is the database's responsibility. Moving data here and there, communicating with the user, and all sorts of other logic details are the app layer's responsibility. Here, the database is just making sure the data is clean. That's all. In my earlier example, the database was setting up a timestamp value for caches. The timestamp is data. The timestamp refers to validity of other data. This can go in the database itself. It's not really anyone else's business.
This should be the app layer's responsibility? I have only these counterexamples. SELECT MAX(lastmod) when there are no triggers and functions (see my previous post). Making sure the MD5 implementation is the same for all client libraries in all languages when there are no triggers and functions.
No code is perfect. I'm not advocating that you rely solely on the database. What I'm saying is that the database can be correctly used as a last line of defense for bad data that somehow crept through.
Every other database has the philosophy that bad data is not allowed. Period. What happens when you leave your company -- or you're on vacation -- and the new guy who is familiar with MySQL just decides to whip up a script to perform some query on the database?
I'm not trying to say that what you have doesn't work for you. I'm saying that what you have is vulnerable to circumvention without malice.
As a side note, your engine sounds conspicuously like EJBs and the
Ummm...so? Java can catch SQL Exceptions, C can check error codes, Perl can trap any error message with eval. If you are seeing messages from the database when you didn't intend to, you have done something wrong. Don't blame the database engine. This is an app layer bug.
In other news, I raise exceptions in stored procedures all of the time. Those error messages are clear, concise English phrases that I specify.
For example, I have this statement in one of those stored procedures called from an insert and update trigger:Seems to me like a friendly and useful database error message to me.
This is a good thing, but it doesn't justify the use of MySQL; It only justifies the use of your object layer. If you took out MySQL support, you could have triggers, stored procedures, views, advanced constraints, custom data types, rules, etc. when you moved from database to database. Why limit your options with MySQL? If it's so that you can support everything, do you also support comma-separated-value files through ODBC as well, or would that be silly? There is always a lower level of functionality.
Just as you wouldn't waste your time with CSV over ODBC because of limited functionality and brittleness, why do you waste your time with MySQL?
Is MySQL faster for SELECTs? Sure. But what people don't seem to get is that with all of those "useless" features of real RDBMSs, you can make a schema that enforces correct data (reducing processing time and complexity in the app layer), and you can have triggers and rules modify cache tables that give commonly used data and/or last-modified info. I don't care how fast MySQL has been or wil be; The fastest queries will always be the ones that you don't have to make as many times. The best use of a database is usually where you don't have to send as much data over the wire in communication.
Example: You have dynamic content, but the interval between updates is large enough to justify caching.
Using MySQL, you would have to insert the data with a timestamp (don't forget the index on the column!), make a query for the newest timestamp using a MAX aggregate, check the timestamp against the cache timestamp, make the real query if the timestamp's newer than cache, get the results back, and update the cache timestamp. Note that you would have to remember to update an entry's timestamp in every part of the code that would ever make updates the table(s). And of course, this is only a single table for granularity. For joins, you would have to do multiple max timestamp checks.
With the others, you would make a cache table with just one timestamp entry for the query -- no matter how many tables it spanned. Note that you have already saved rows*sizeof(timestamp)*tables in space over MySQL as a bonus, so your tables are more likely to fit into physical RAM for greater performance. Next you would write an insert and update trigger for the tables that would update this cache timestamp value on changes. The logic for this is located in only one place: the source of the data.
Using a database other than MySQL, you would insert the data without a timestamp (handled internally by the database), SELECT on the very small cache table for one entry, compare against your local cache timestamp, make the real query if the timestamp's newer than cache, get the results back, and update your app cache.
I don't care how fast you think MySQL is. It will never be able to make repeated "SELECT MAX(modified) FROM bigtable;" calls faster than repeated "SELECT modified FROM cache WHERE key = 'somedatamodel';" The overhead of updating a single or small number of rows to change a timestamp value is lost in the overall insert or update processing (no index and it's update overhead is necessary for that small a table). And any client, custom object model or no, will work.
THIS is why I have a problem with MySQL. It isn't some esoteric feature. I want to scale. No database benchmark will adequately demonstrate this when all it is comparing is SELECT and INSERT performance. I want to set up my database and go -- not constantly tweak my app layer to fudge a few milliseconds of processing time less or sacrifice data dynamism. It's not that the other databases are more feature-rich; MySQL is feature-poor. Will it work for small installations? Sure, but so will any other database out there. The small problems are easy. It's the big problems -- or the small problems that steadily grow -- that demand our attention.
If you want to use it, that's your decision. But don't delude yourself or others into thinking it is the optimum solution.
No, because according to the rules of English, you shouldn't. According to those same rules of English, book titles are italicized or, in the case of handwriting, underlined.
You are among a small minority. Parentheses are commonly used for asides that do not fit within the context of the associated sentence.
_Book Name_ is more common in practice. This is one of the many areas where plain text is deficient over a document with structured formatting.
If you really want to split hairs, you shouldn't have used parentheses in your last sentence as the parenthetical material is closely associated with the content of the enclosing sentence. As a comma is too soft a break in the flow of the sentence, it would have worked better with an mdash.
"Besides, if you were to do this in plain text -- to which all html should downgrade gracefully -- quotes are the common way to denote a book name."
I realize that two hyphens are not technically an mdash, but at least it holds some semblance of correctness. Think of English as a complex programming language and the reader as a compiler or runtime environment. The more strict the input, the faster it gets processed.
Your use of italics in parentheses and quotes around book titles is akin to errant C macros that redefine core functionality. It obfuscates. You are, of course, entitled to your own writing style, but don't presume that it's correct or encourage others to adopt the practice.
Just because people are largely ignorant of the rules of English does not mean that those rules do not exist. It's a crying shame that grammar isn't taught in most U.S. public schools anymore.
FYI: I studied literature in college; however, I thought that an analogy to programming would go over better in this forum.
Don't forget "secure." C allows no protection from buffer overflows and other sundry security holes. Is it possible to code safely in C? Sure, but 99% of all existing C coders cannot.
An IMAP server is an example of a widely available network service. Even if the IMAP server is slower because it was written in Python, you have a dramatically lower chance of opening up a remote root exploit.
It all falls on where your priorities lie. I'd say that programmers these days should err on the side of safety for the sake of their users and not on squeezing the last bit of speed out of an implementation detail (choice of language).
Indeed I was paying attention. And you've never kissed someone with your eyes open? How old are you? Twelve?
Fine. Let's say I missed this subtle eyeball powerplay. This cunning conquerer of millions of worlds was ultimately tricked by one android. The most efficient method to conquest, apparently, was to seduce Data and coerce his actions.
Sure, he "encrypted" the computer's databank. Tell me, do you think today's codebreakers would have a problem with anything devised in the fifties? Now realize that the Borg are more than fifty years ahead of the Federation in technology -- they've assimilated all of the cryptographic techniques of millions of worlds!
But okay...let's assume that she can't decrypt it. She's under time pressures and all. After Data decrypted the computer, what efficiency reason is there to rely on him for anything ever again? It would've been more efficient for the queen to destroy the warp test vessel herself.
And what part of efficiency justifies her fixation on Picard? What possible purpose did it serve? He doesn't want to be her boy toy? Fine. Assimilate him and send him to the drone mines. But no, she went on a whole, "I've got a new man and he's better than you were anyway." Uh hunh. Talk about petty. Oh wait! Pettiness is tied to emotions. I guess she let her emotions mislead her after all.
"...only so much of their linear behaviour you can take."
Funny. That linear, rigid, unerring behavior is precisely why the Borg became Trek's favorite villain. Everything they did in First Contact made the Borg less intimidating and weaker. Give me linear behavior any day!
The primary point to the Borg was that there was no individuality -- no personality. Then they manufactured individuality and personality into the Borg at a basic level. Don't get me started on that "Unimatrix 0" crap in Voyager.
When the first cube came into Federation space, it completely demolished basically the entire fleet. Now this time, Picard knows the weakness that allows it to be destroyed no problem. Funny, I thought the whole point to the cubes was that there was no central weak point. Everything was redundant -- including the crew. THAT was scary. A systemic command to sleep was the only thing that saved them on that first encounter. Now they just aim for the weak spots. Nice. After millions of worlds, only the Federation seems to find these weak spots.
Star Trek died with Roddenberry.
He didn't say it didn't exist. He said that it costs money and doesn't come with the main distribution.
Precisely where it shouldn't need to be. You should be able to make a database schema, populate it with data, and know that your data is safe and consistent. Any bad db admin can muck up a schema, but MySQL prevents the good DB admins from doing their job properly.
It is rare that any non-trivial application has only one developer or cohesive group. Database schemas are usually designed by a single person or core group. Can you assert that everyone you work with will clean the user input correctly or work delete a record that another record depends upon? If you design your schema correctly, the DELETE either fails or deletes all of the records that relate to it depending on what data model you choose. An INSERT, UPDATE, and DROP is similarly constrained -- and all or nothing affair with no ambiguities in between.
Your app code can have some checks. Too many checks never hurts quite as much as too few. With PostgreSQL, SAP DB, Oracle, MS SQL, Sybase, DB2, etc., the database is a valid last line of defense against invalid data. They can be made to NOT ALLOW bad data to enter or become bad after it's in. This is the default behavior and not a special set of tables you choose when you download the "Max" version.
If your data is important enough to store, it's important enough to protect. If integrity doesn't matter as much, if your data isn't that important, just use a flat file -- it's much faster for reads and caches well. Or you could put SQUID in front of your web app in which case the database needs to be just fast enough...
Now then, a question: Does MySQL have support for cell constraints like limiting an integer field to a value between 15 and 90 or making sure that a text field has at least seven characters or matches a valid social security number? This is not flamebait; I don't know, and I'm curious. I don't see mention of them on a search of "constraint" on the mysql.com. I certainly hope it does or I'll have a new thing to bitch about with MySQL.
First Contact the best!?! You've seen the other movies right?
2 566
http://slashdot.org/comments.pl?sid=47858&cid=488
Star Trek: First Contact (8)!?!
You're kidding right? This was noticeably better than Star Trek 4? It wasn't even good!
What about the Borg scared the crap out of us when we first saw them? The hive mind. The collective. The lack of individual thought. The elimination of self...utterly. It was worse than servitude or slavery. It was the complete annihilation of everything you are, were, and ever would be. You are a number.
Then they introduce a "queen." The Borg isn't a hive mind anymore; It's an extension of the queen. Well then, just kill the queen (like in Voyager...ugh). I can't believe anyone is forgiving the script writers for things like Picard "forgot" about the queen and her wanting someone at her "side." Yeah, because with the chorus in her head, she's lonely. Yeah, after millions of worlds, now she could use some help. Yeah, after millions of worlds, she needs *Picard's* help.
The Borg became too...human. What would the Borg of the series have done when in contact with Data? Ohh! Neat technology. *sucking sound*
But no! In First Contact, the Borg sprouts a queen, she gets her nipples hard over Data, and allows her emotions (!!!) to mislead her. She was actually bitter because she lost Picard! She apparently is responsible for the cultural vacuuming of trillions of beings, but somehow Picard and Data were "special."
This is the Borg!! Why would they need love, companionship, reproduction, or sex? If they wanted to feel good, they can just flip a switch and have a collective orgasm.
But yeah, some dialog about Moby Dick and Troi getting drunk definitely made up for it. Puhleese!
Didn't anyone else notice that the movie neutered Star Trek's best adversary? I feel like I'm taking crazy pills!
The main problems with it versus broader garbage collection schemes are circular references and overhead.
If two (or more) objects have a reference to one another, the count can never reach zero even if nothing in the main logic points to those objects anymore.
Also, every time an object gains or loses a reference, a check for a count of zero is made. In fuller garbage collection setups, periodic checks are made to all of the objects in a low-priority thread. In some cases, memory usage can be higher, but performance is also higher sometimes and it can handle circular references.
Both are better than repeated use of malloc/free and new/delete though.
--
C also muddies this concept because there are no objects in C.
in that folks who use C can avoid common pitfalls. But so much of this seems like it has been tackled by C++. Only C++ did it cleaner. C++ is complex though. So this only leaves (horrors) a higher level language that removes all of these implementation details that lead to insecure programs.
Do it in a higher-level language first. Make sure your algorithms are clean and efficient. If and only if you see a performance or resource problem do you rework portions(!!!) in C. As a bonus, the higher level language acts as a code template for faster C development.
Once you are at that point, this Mini-HOWTO will definitely be a great resource to use.
If you're willing to hang someone upside-down from their toenails, would you really care about the license terms of some software?
Their hearts are the right place, but c'mon! Let's say Amnesty International comes forward saying that Regime X violates human rights. Then you find out that Regime X is using your software. Do you believe that Regime X, torturer of thousands, gives a rats ass about some programmer's licence terms?
Do you think that your government is going to say, "Well sure, they sodomize children in the factories, but let's try economic sanctions because of their software license violations."
-----
On a side note, the U.S. is routinely criticized for the continued use of the death penalty, the living conditions of prisoners, domestic spying, imprisonment without due process, and other sundry items. Since the U.S. is a democratic republic, does that mean that everyone in the U.S. is forbidden the use of this software due to their complicity in human rights violations?
You're absolutely right about using BEGIN/COMMIT/ROLLBACK. However, simple UPDATE statements also use transactions without that syntax. All statements are protected and atomic in PostgreSQL. You only need BEGIN/COMMIT/ROLLBACK for a group of statements. A newbie who doesn't fully understand ACID can still take advantage of the protections afforded by ACID.
As for MySQL, how does he know when to use InnoDB versus MyISAM, BDB, HEAP, MERGE, etc.? My point was that in other databases, the default behavior is to protect the data. You should have to choose speed, not safety. If InnoDB was the default, while I would still have reservations about MySQL, it would allay many of my concerns regarding its general use by newbies.
Once again and with feeling, "Joe Newbie doesn't automatically need to use every feature of PostgreSQL." Just as beginning programmers don't need to know how to do memory mapping, you don't need to write triggers. But if they ever need to use memory mapping, isn't it nice to know that it's there?
*** As a side note, transactions took me less time to figure out than SELECT, INSERT, UPDATE, and DELETE. Views took me two minutes. Triggers and rules took a little bit longer. I worry about folks who say that PostgreSQL is too complex to figure out. Intelligent database design takes much longer to figure out than query semantics. This "simpler" mantra from the MySQL camp sounds like a red herring these days.
If all you need is CREATE TABLE, INSERT, UPDATE, SELECT, and DELETE, then just use those constructs. Nobody's holding a gun to your head forcing you to use stored procedures. But if a problem comes up down the line that is perfect for a view, why not use it? The only reason I can see not to is if you are saddled with MySQL.
The data may not be relied upon for extended periods of time, but its integrity is still important.
You don't care about errors in your web statistics? Why gather them in the first place then? I'm not talking about storing last week's stats; I'm talking about using this week's.
The best case scenario for an invalid cache entry is that the app ignores it. The worst case is that bad data is used. This is not acceptable. If the data is unreliable, why are you using it? Why not pull from
If *you* decide to discard the data after a few seconds, that's your prerogative. But it should always (always!) be your decision as a user of programmer -- not the result of a data integrity issue.
Non-determinism is the harbinger of a little mind.
You are indeed correct. I mistyped. With updates like in my example, you don't have to explicitly lock a table. Strictly speaking, you don't have to in MySQL either; you just do it with some risk to your data.
In the next versions of PostgreSQL, support for nested transactions would solve those particular problems. But as that's a feature not yet available, I cede the point.
In your example, a lock is indeed the way to go.
No, MySQL *can* be ACID-compliant. It is not by default. A new user would not necessarily know that they have to use an "atomic" or "transaction" table. MySQL is supposedly newbie-friendly. Yet they must determine advantages of MyISAM over InnoDB over plain tables. For a newbie user of PostgreSQL, they can just create a table and be done with it.
I disagree that ACID can ever be optional. Once again, if it's important enough to store, it's important enough to protect.