catting requests and parsing results, are you kidding me?

Started by
4 comments, last by rip-off 13 years, 1 month ago
Warning, this is mostly rant, but I want to know if others feel the same way:

To parse XML in C++ using a common library, such as QtXmlQuery, at runtime you create concat a bunch of strings together to form an xpath for what you want, send in the strings, which the library parses out a set of instructions, and returns the result, usually as a string, which your program must parse.

Want a file format experience better than serializing your data into strings and writing a text file? Try SQLite. Your C program just cats together a string full of SQL commands, which SQLite parses and runs. Really? Doesn't "SELECT FOO WHERE X=" << x << " AND Z =" << z drive you nuts? You could use '?' and bind a variable, but that's almost as bad. You are now serializing your data, intermixed with SQL keywords.

Is this what software is turning into? Just a bunch of libraries that communicate with each other through text strings? It's pretty sad for simple data elements, such as integers, which get repeatedly serialized into strings and reparsed into ints. I think its absolutely insane. For one, you have no idea about errors in the generated string code until run time

What do you think?
Advertisement
So...

You use XML and SQL, then complain about XML and SQL?

To parse XML in C++[/quote]There are many XML parsers. There are also several XPath implementations. It's definitely possible to use combinations thereof in C++. But is that what you need to do?

Want a file format experience better than serializing your data into strings and writing a text file? Try SQLite.[/quote]Well, SQLite is one way to persist data, sure. For traditional serialization, something like ProtocolBuffers is much more suitable. But SQLite allows queries to be performed as well, which might be a plus.

Just a bunch of libraries that communicate with each other through text strings?[/quote]
Well, this is what it has always been like. It was only a few brief years that Microsoft tried something else, but that didn't work out in the long run.

*nix = files + pipes + shell, everything is human readable text
web = text

I think its absolutely insane. For one, you have no idea about errors in the generated string code until run time[/quote]Again, depends what these things are used for. No context is given here. SQL is a well known query language used by majority of the industry, so these issues are apparently not paramount.


PS: If using XML or SQL, C++ is the wrong language to be working in.
Use the right tool for the job. Write your code in a language that actually has decent string operation and late-binding data support, and XML/SQL/etc. become a breeze.

C (let alone C++) is not for data-heavy backend work. This is where the "scripting languages" really shine.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

It should be stressed that you MUST use bind variables with SQL; concatenating pieces of SQL and variable values like in your example is wrong, not inconvenient.

Omae Wa Mou Shindeiru


Warning, this is mostly rant, but I want to know if others feel the same way:

To parse XML in C++ using a common library, such as QtXmlQuery, at runtime you create concat a bunch of strings together to form an xpath for what you want, send in the strings, which the library parses out a set of instructions, and returns the result, usually as a string, which your program must parse.

Want a file format experience better than serializing your data into strings and writing a text file? Try SQLite. Your C program just cats together a string full of SQL commands, which SQLite parses and runs. Really? Doesn't "SELECT FOO WHERE X=" << x << " AND Z =" << z drive you nuts? You could use '?' and bind a variable, but that's almost as bad. You are now serializing your data, intermixed with SQL keywords.


That's using SQLite (or any other sql database engine for that matter) very poorly. The right way is to precompile the SQL statements you're going to use at the beginning, then use variable bindings.
This way you don't parse the SQL multiple times, you don't output integers and such to strings that are subsequently reparsed to ints, and more importantly, you don't run the query planner multiple times. And in the context of a web app you also avoid being vulnerable to SQL injection.

In SQLite's case, a statement is turned, after parsing, into byte code that implements the the query (that runs into a specialized VM that provides such operations as index accesses, loops, column/row value retrieval and such), and the value of bound variables are accessed directly by the byte code (so they are not converted to strings and back).

I am no fan of XML in any way but I suppose that any decent XPatch engine would allow to pre-parse xpath queries as well.

And in the context of a web app you also avoid being vulnerable to SQL injection.[/quote]
You don't have to be running a webapp to be vulnerable to SQL injection. Using any user-submitted string directly in a SQL query could create problems. They are most notable in any multi-user/player context, because these typically try to sandbox users away from one another. At the very least allowing user-entered text could cause the SQL parser to reject statements, which could cause failures or crashes even in single player games.

This topic is closed to new replies.

Advertisement