Menu
▾
▴
corelinux-develop
|
From: Frank V. C. <fr...@co...> - 2001-01-14 03:16:24
|
Pun intended :) Anyway, my initial thoughts (from real world experience) is to avoid the stream operator persistence protocol. In other words, real world systems don't store data in blobs. While it may be easy for the application developer, it results in poor performance, poor scalability, and a nightmare when the data store exceeds some physical limitation. Furthermore, classes aren't modeled in single monoliths, and the persistent framework should reflect that object oriented applications are hierarchical by and far, shouldn't the data be as well? Thoughts? -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Christophe Prud'h. <pru...@MI...> - 2001-01-16 04:00:12
|
On Saturday 13 January 2001 20:01, you wrote: > Pun intended :) > > Anyway, my initial thoughts (from real world experience) is to avoid th= e > stream operator persistence protocol. what is this ? is it just the << op used to store the relevant data? > > In other words, real world systems don't store data in blobs. While it > may be easy for the application developer, it results in poor > performance, poor scalability, and a nightmare when the data store > exceeds some physical limitation. yes and no. In my case, the data is few big, very big blobs which are scattered over=20 filesystems using parallel virtual filesystems. > > Furthermore, classes aren't modeled in single monoliths, and the > persistent framework should reflect that object oriented applications > are hierarchical by and far, shouldn't the data be as well? yes. I personnally deal with persistence using very specific solutions for my=20 domain (scientific computing) and they are not really -- I think --=20 applicable to real world applications. On this topic I agree with you Am I wrong if I say that XML seem to be a language of choice to store dat= a=20 for object ? It seems that it is heavily used these days as the language = of=20 choice for configuration files and persistence.=20 my 2 cents C. --=20 Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | Somebody once asked me if I though= t sex Cambridge MA 02139 | was dirty. I said, "It is if you'r= e Tel (Office) : (00 1) (617) 253 0229 | doing it right." Fax (Office) : (00 1) (617) 258 8559 | -- Woody allen http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2001-01-16 11:08:42
|
Christophe Prud'homme wrote: > > On Saturday 13 January 2001 20:01, you wrote: > > Pun intended :) > > > > Anyway, my initial thoughts (from real world experience) is to avoid the > > stream operator persistence protocol. > what is this ? > is it just the << op used to store the relevant data? Yes > > In other words, real world systems don't store data in blobs. While it > > may be easy for the application developer, it results in poor > > performance, poor scalability, and a nightmare when the data store > > exceeds some physical limitation. > yes and no. > In my case, the data is few big, very big blobs which are scattered over > filesystems using parallel virtual filesystems. Don't discount the power of abstraction!!! :) > > Furthermore, classes aren't modeled in single monoliths, and the > > persistent framework should reflect that object oriented applications > > are hierarchical by and far, shouldn't the data be as well? > yes. > I personnally deal with persistence using very specific solutions for my > domain (scientific computing) and they are not really -- I think -- > applicable to real world applications. > > On this topic I agree with you > Am I wrong if I say that XML seem to be a language of choice to store data > for object ? It seems that it is heavily used these days as the language of > choice for configuration files and persistence. XML is being abused as it is perceived to be the panacea of computing. XML SHOULD be used to interchange information between systems so that they can readily parse the structure (converting and/or using it as they choose). For that reason I believe XML is a wonderful thing (not counting the issue about structural reasoning). It is NOT meant to be readable (configuration), nor does it perform when used as a database (persist). I'll see your 0.02 and raise you 0.02! > > my 2 cents > C. > -- > Christophe Prud'homme | > MIT, 77, Mass Ave, Rm 3-243 | Somebody once asked me if I thought sex > Cambridge MA 02139 | was dirty. I said, "It is if you're > Tel (Office) : (00 1) (617) 253 0229 | doing it right." > Fax (Office) : (00 1) (617) 258 8559 | -- Woody allen > http://augustine.mit.edu/~prudhomm | > Following the hacker spirit > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/lists/listinfo/corelinux-develop -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Christophe Prud'h. <pru...@MI...> - 2001-01-17 03:48:44
|
Another 2 cents:) should the data be human readable ? That is, is it of interest to be able to edit "by hand" the "state" of an= =20 object ? is it a concern for the framework or for the user of the framework ? Otherwise it appears to me that a structured/hierarchical way of storing = data=20 would be best for the persistence framework. C. --=20 Christophe Prud'homme | Pierre: Je suis d=E9sol=E9 Th=E9r= =E8se, je ne MIT, 77, Mass Ave, Rm 3-243 | sais pas ce qui m'a pris.= =2E. Cambridge MA 02139 | c'est une catastrophe. Tel (Office) : (00 1) (617) 253 0229 | Th=E9r=E8se: Ce n'est rien Pierre= , Fax (Office) : (00 1) (617) 258 8559 | je n'ai rien senti.... http://augustine.mit.edu/~prudhomm | -- Le Pere Noel est une ordure Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2001-01-18 11:05:27
|
Christophe Prud'homme wrote: > > Another 2 cents:) > > should the data be human readable ? I believe that is the question to the person who writes the concrete persistent implementation classes. > That is, is it of interest to be able to edit "by hand" the "state" of an > object ? Again, is that our concern in the abstraction? > is it a concern for the framework or for the user of the framework ? Well, it is not of concern for the CoreLinux++ group as long as we don't BREAK the ability to do what the implementation needs to do. > > Otherwise it appears to me that a structured/hierarchical way of storing data > would be best for the persistence framework. > > C. > -- > Christophe Prud'homme | Pierre: Je suis désolé Thérèse, je ne > MIT, 77, Mass Ave, Rm 3-243 | sais pas ce qui m'a pris... > Cambridge MA 02139 | c'est une catastrophe. > Tel (Office) : (00 1) (617) 253 0229 | Thérèse: Ce n'est rien Pierre, > Fax (Office) : (00 1) (617) 258 8559 | je n'ai rien senti.... > http://augustine.mit.edu/~prudhomm | -- Le Pere Noel est une ordure > Following the hacker spirit > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/lists/listinfo/corelinux-develop -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
