Since I know it was discussed in the past (but I could not find the post in the archives) I hope to be "original" by not reiterate old ideas.
BTW I start from a reply to a previous post to explain what I would need to use plan 9 for web development. But first of all, I have to say that I'm not (yet) a Plan 9 user/developer, just a programmer who studied it and loved its potentialities. Actually I'm thinking about how to use Plan 9 in web development (real one, I'm not talking about having a blog or a shinny flash site), and I'm proposing a structure for data access towards a dbfs interface. The scope is to be able to query the db towards a filesystem, with no need to use different libraries for different db backend... each application would use a filesystem, while each rdbms would have it's own filesystem (all with the same structure, obviously) Now the WHY I think such an interface matter: On Fri, Nov 21, 2008 at 7:12 PM, <[EMAIL PROTECTED]> wrote: > On db ↔ fs conversions: > // datas (and their relations) MUST be kept consistents. > > there's two things you could mean here: either the > relations between the data fields/types or the relations > between their values. Both are really important. When a product change its code (aka pk) for business' reasons, I need have it changed automatically in any place its referred in the database. Or if a dumb employee try to delete a product category (supposing he's allowed) I have to be sure that the remaining data don't loose meaning. SQL databases are interesting because they don't do anything to keep the > relations > consistent, at a schema level. They do, if you instruct them about the relations amont your tables. (MS Access don't count as a db :-D) > there are some cases where > this is valuable, but most of the time it just puts more of > the burden on the application. Application should HANDLE data. But datas are a rapresentation of a reality which have a meaning! A relational database don't have to know how datas are collected or used. But it has to keep meaningfull the rappresentation. > enforcing consistency between values is a whole different > matter. Obviously I'll check user provided data types before sending them to the db. BTW, db also have to, for different reasons. I've to protect my database from malicious sql injections, it has to protect datas from inconsistency (say a string in a date field). and largely needs to be done in the ap anyway (say > your DB rejects a submission; are you just giong to panic, > say "try again", or try and figure out what it didn't like?). Well, accoding to the needs, different strategies are followed. Sometime the error will go (human translated :-D) to the user, others a signalation will go to the developers. Here is a disadvantage: user provided data are double checked (some time checks are 3, when also a remote client do the check, say via javascript). I reflected a lot about this, but (still) found no solution. I just notice that the reasons for the checks are different: 1. DB check to keep data consistents 2. Application check to validate data against malicious ones 3. (eventually) browsers check to help the user and to save a little of band If you need data consistency (anyone need I think) DB have to check. If you can't trust the user application have to check. If you don't have enouth Gbits you could also need to repeat the data check in the browser. > // And MUST be updated frequently, in transaction. > > just curious: what is it about "transactionality" that you care > about? atomicity, logging, roll-back (atomic roll-back)? > Atomicity and rollback. (logging is useful too...) I need to be able to atomically save related tuples in different tables, since (for example) those different tables could be simply modelling ONE real entity (say an order or a family). // Application code cannot do that, since it's too subject to > // modifications... > > i'm not convinced. you can simply... not modify it! You are right... I like my applications... (almost all...) I really don't want... but they paid me! :-D > unless you've got a database you're exposing to multiple parties > and you're worried one is going to mess things up for > others, but in that case i think exposing the database > directly is pretty risky regardless. There why we use REST... but that's another history... > the application i've worked on with the most complex data > constraints had an "ontology layer" that everything that > wanted to do data access went through. 'till now our "ontology layer" was the database itself. But I would be curious about how this ontology layer was implemented. Really! > // Moreover such a dbfs should allow rapid development of > // views over data (with different permissions) by simply > // write the query in a file and then open the file for reading > // the XML. > > somewhere around here i've got a /chan/pq for inferno that > makes connections to a pq database. each open is a new > logical connection; you write the query and read the result. > results were not in XML, and pq has no updates (at current). where? I could start from there... (even I'm sure that it has to be coded in C) > i think you've got some very interesting ideas on sessionfs > in particular. i have more thinking to do there. You're welcome! I realized that the sessionfs has to cooperate with the rewrite engine... > oh, probably an aside: from an application design point of > view, DO NOT empty my shopping cart just because my > session timed out. i should be able to pick up where i left > off. i'm not sure how hypothetical that example was, but > that's a common source of irritation for online shopping. It was hypothetical. But, to keep back your cart you MUST be logged (some times adding to the shopping cart don't require authentication) and the cart status have to be saved somewhere (the database?). Note that such a strategy could lead to problems too: what about if you fill a shopping cart with discounted products and submit it a month later, when discounts disappear? Are you sure you would be check if the prices have changed? I think so... you use Plan 9... But customers, often, use Windows... they are not so smart! :-D Giacomo
