From: Emiliano <em...@ir...> - 2000-11-17 07:35:09
|
Hi all, I'm in the process of comparing several databases in order to pick one for my project. Where would you guys say that the strong and wek points are of Sanchez? Where does it excel? And does it support BLOB storage? I couldn't find anything about it in the docs. Emile |
From: Thomas G. <to...@ad...> - 2000-11-17 14:09:53
|
On Fri, 17 Nov 2000, Emiliano wrote: > Hi all, > > I'm in the process of comparing several databases in order to pick one > for my project. Where would > you guys say that the strong and wek points are of Sanchez? Where does > it excel? And does it support > BLOB storage? I couldn't find anything about it in the docs. > > Emile Emile, That is a loaded question! Are you only interested in hierarchical data storage or is something relational an option? I like GT.M so far but it doesn't sport the wide variety of interfaces of some relational databases, most notably my favourite: Postgres. (Accessed via { Perl | Python | TCL/tk | JDBC | ODBC | C | PHP } ) Now, I better get out of here before someone throws something at me! Cheers, Tom -------------------------------------------------------------------- SVCMC - Center for Behavioral Health -------------------------------------------------------------------- Thomas Good tomg@ { admin | q8 } .nrnet.org IS Coordinator / DBA Phone: 718-354-5528 Fax: 718-354-5056 -------------------------------------------------------------------- Powered by: PostgreSQL s l a c k w a r e FreeBSD: RDBMS |---------- linux The Power To Serve -------------------------------------------------------------------- |
From: K.S. B. <k.b...@sa...> - 2000-11-17 15:26:53
|
Emile -- The strong points about GT.M are performance / scalability, and robustness / reliability. On x86 GNU/Linux, price is also a strong point. On other platforms, we at Sanchez like to think that our pricing, even though it's not zero, is still reasonable. On a high end PC class platform, rates of hundreds of transactions per second have been achieved, and on an RS/6000 platform, rates of between one thousand and two thousand tps with full ACID properties have been published. All this is on single machines with multiple CPUs. For robustness / reliability, GT.M has unique features for developing applications that must be continuously available, even when a data center is put out of action, or when a software upgrade requires changes to the database schema (details are in the Administration and Operations Guide). Depending on your point of view, the fact that the native language for application development today is M is either a strength or a weakness. Once the source code is released, or as soon as the C to M call in interface is released, you will be able to program in C/C++ as well. This means that GT.M as it stands does not have the ability to access the database like a standard relational database. If your data model is relational, you can use a product, KB_SQL, from KB Systems (http://www.knowledgebasedsys.com) for SQL/ODBC access to your data. There may be an open source solution in the pipeline. Since GT.M can read and write sockets, and named pipes, interfacing Python, Perl, TCL, etc. to GT.M is reasonably straightforward but certainly harder than falling off a log. Web access to GT.M is available today via a CGI interface. I don't know to what extent the other freeware databases have industrial strength transaction processing capabilities and/or have been vetted in production (GT.M has been in production since 1986, and is licensed for use in over 1,000 institutions). I hope this answers your questions. If not, please do ask. Regards -- Bhaskar K.S. Bhaskar VP, Greystone Group Sanchez Computer Associates, Inc. 40 Valley Stream Parkway Malvern, PA 19355, USA +1 (610) 578-4265 k.b...@sa... |
From: Thomas G. <to...@ad...> - 2000-11-17 16:05:05
|
On Fri, 17 Nov 2000, K.S. Bhaskar wrote: > Since GT.M can read and write sockets, and named pipes, interfacing > Python, Perl, TCL, etc. to GT.M is reasonably straightforward but > certainly harder than falling off a log. Web access to GT.M is > available today via a CGI interface. Can you point me to the docs on this Bhaskar? I've just now visited your new page and it states that a URL will be provided soon. This is of particular interest to me as we have an intranet that accesses Postgres data via Perl/CGI and I am now writing code to do the same for GT.M. In fact, I have a crude but effective initial bit of code. Crude because it has a perl cgi form collect user input and then generates an M routine, passing the routine to the mumps binary for linking and execution. If you have a CGI interface that is ready for primetime it could save me reinventing the wheel. TIA -------------------------------------------------------------------- SVCMC - Center for Behavioral Health -------------------------------------------------------------------- Thomas Good tomg@ { admin | q8 } .nrnet.org IS Coordinator / DBA Phone: 718-354-5528 Fax: 718-354-5056 -------------------------------------------------------------------- Powered by: PostgreSQL s l a c k w a r e FreeBSD: RDBMS |---------- linux The Power To Serve -------------------------------------------------------------------- |
From: Emiliano <em...@ir...> - 2000-11-17 22:09:14
|
K.S. Bhaskar wrote: > The strong points about GT.M are performance / scalability, and > robustness / reliability. On x86 GNU/Linux, price is also a strong > point. On other platforms, we at Sanchez like to think that our > pricing, even though it's not zero, is still reasonable. Since you bring up the subject: is GT.M going open source, or is it freely available for Linux? The expression 'Open Source for Linux x86' sounds off :) > Depending on your point of view, the fact that the native language for > application development today is M is either a strength or a weakness. > Once the source code is released, or as soon as the C to M call in > interface is released, you will be able to program in C/C++ as well. So is there currently _no_ way to get at the data from C? Must applications be written entirely in M? That would be a problem for me. > This means that GT.M as it stands does not have the ability to access > the database like a standard relational database. Which suits me fine. I want to move away from relational. > Since GT.M can read and write sockets, and named pipes, interfacing > Python, Perl, TCL, etc. to GT.M is reasonably straightforward but > certainly harder than falling off a log. Web access to GT.M is > available today via a CGI interface. This sounds very interesting indeed. Can you explain how this read and write works? Is this for stored data access? Query submittal? > I hope this answers your questions. If not, please do ask. Could socket access be used to make blobs available via the database? Emile |
From: K.S. B. <k.b...@sa...> - 2000-11-17 23:46:24
|
Comments embedded below. -- Bhaskar On Friday, November 17, 2000 at 23:09:12 (GMT+0100), Emiliano wrote: > K.S. Bhaskar wrote: > > > The strong points about GT.M are performance / scalability, and > > robustness / reliability. On x86 GNU/Linux, price is also a strong > > point. On other platforms, we at Sanchez like to think that our > > pricing, even though it's not zero, is still reasonable. > > Since you bring up the subject: is GT.M going open source, or is it > freely available for Linux? The expression 'Open Source for Linux x86' > sounds off :) [KSB] The binaries on Source Forge today, and the source code that we will release, will only run unchanged on x86 GNU/Linux. There is no restriction on porting the software to other platforms (in particular, I am personally looking for someone to port it to a PDA!), but this is nontrivial work because although the database code is highly portable across UNIXes, there is a compiler for the M language that will have to be retargeted. It's largely table driven, and it generates threaded code, so this is not hard, but it's more work than just recompiling it on a new platform. > > Depending on your point of view, the fact that the native language for > > application development today is M is either a strength or a weakness. > > Once the source code is released, or as soon as the C to M call in > > interface is released, you will be able to program in C/C++ as well. > > So is there currently _no_ way to get at the data from C? Must > applications be written entirely in M? That would be a problem for me. [KSB] There is currently the ability to call C code from M. We do plan to add the ability to call M code from C in the near future, but it is not there today. Of course, once the source code is released, you can simply take the run time libraries and link them with your C application, bypassing M altogether... > > This means that GT.M as it stands does not have the ability to access > > the database like a standard relational database. > > Which suits me fine. I want to move away from relational. The native database of M is sparse hierarchical associative memory, with indices and data completely untyped (i.e., BLOB is the native datatype!). For example: GTM>set ^x=2 GTM>set ^x("Emiliano")="Iris Advies" GTM>set ^x("Bhaskar")="Sanchez" GTM>set ^x("Bhaskar","Sanchez")="Malvern, Pennsylvania, USA" GTM>set ^x("Bhaskar",$char(3))=$char(5) GTM>zwrite ^x ^x=2 ^x("Bhaskar")="Sanchez" ^x("Bhaskar",$C(3))=$C(5) ^x("Bhaskar","Sanchez")="Malvern, Pennsylvania, USA" ^x("Emiliano")="Iris Advies" GTM> As you can see, the same variable (^x) has a scalar value, an array element with one index, array elements with multiple indices, array elements that are binary data $c(3) is a control-C, etc. The closest analogs to M variables are awk arrays and Snobol4 tables. Database accesses are just like array accesses, except that they are shared (if one process sets it, another can read it), and persistence (if you shut down the computer and come back tomorrow, it's still there). Of course, there is support for full ACID transactions. Get a book by Richard Walters called M Programming: A Comprehensive Guide to learn more, or just download GT.M, read the manuals, and start playing. > > Since GT.M can read and write sockets, and named pipes, interfacing > > Python, Perl, TCL, etc. to GT.M is reasonably straightforward but > > certainly harder than falling off a log. Web access to GT.M is > > available today via a CGI interface. > > This sounds very interesting indeed. Can you explain how this read and > write works? Is this for stored data access? Query submittal? [KSB] M is a complete programming language that gives you complete database access. To process a query, you have to define your query language (since SQL doesn't work for hierarchical data), process the query in M and return the result. The SQL engines that work on M databases define a relational mapping to the data in the M database, and then have an engine for processing SQL written in M. READ and WRITE are M language elements for reading and writing streams of bytes from files, terminals, named pipes, and TCP sockets. > > I hope this answers your questions. If not, please do ask. > > Could socket access be used to make blobs available via the database? [KSB] Absolutely! |
From: Emiliano <em...@ir...> - 2000-11-18 12:19:31
|
K.S. Bhaskar wrote: > > Since you bring up the subject: is GT.M going open source, or is it > > freely available for Linux? The expression 'Open Source for Linux x86' > > sounds off :) > > [KSB] The binaries on Source Forge today, and the source code that we > will release, will only run unchanged on x86 GNU/Linux. Just out of curiosity: why did GT.M go Open Source? And if you're going Open Source, why not make the source available today? > There is no > restriction on porting the software to other platforms (in particular, > I am personally looking for someone to port it to a PDA!), Hmm, this could be interesting for me. Is it potentially that lightweight? > but this is > nontrivial work because although the database code is highly portable > across UNIXes, there is a compiler for the M language that will have to > be retargeted. What's the status of this compiler? Will it be opensourced too? Will the database be useful without? > It's largely table driven, and it generates threaded > code, so this is not hard, but it's more work than just recompiling it > on a new platform. I see. It's not a p-code compiler of sorts then? It spits out native binaries? > > So is there currently _no_ way to get at the data from C? Must > > applications be written entirely in M? That would be a problem for me. > > [KSB] There is currently the ability to call C code from M. We do plan > to add the ability to call M code from C in the near future, but it is > not there today. > > Of course, once the source code is released, you can simply take the > run time libraries and link them with your C application, bypassing M > altogether... If that still discloses the database functionality, that would be fine with me. I'm building an apache/php module that will need to access the database, so the ability to call from C (or C++, but C preferred) is a must-have for me. More specifically, we're building a content management system, and what we want is a loose hierarchy of free-form objects where it's possible (and easy, preferably) to add properties (fields, blobs) to objects at runtime. It should be possible to get a object description (what fields/what type) given an object. Objects could be as lightweight as appointment records (just a date + people involved in a simple case) or entire binary documents. On a scale from "you can do that" to "you're going to do _what_?!", where would you place using GT.M for this purpose? > > Which suits me fine. I want to move away from relational. > > The native database of M is sparse hierarchical associative memory, > with indices and data completely untyped (i.e., BLOB is the native > datatype!). For example: What size restrictions do BLOBs have? Can I fetch parts of them, or can I get them in chunks? > GTM>set ^x=2 > GTM>set ^x("Emiliano")="Iris Advies" > GTM>set ^x("Bhaskar")="Sanchez" > GTM>set ^x("Bhaskar","Sanchez")="Malvern, Pennsylvania, USA" > GTM>set ^x("Bhaskar",$char(3))=$char(5) > GTM>zwrite ^x > ^x=2 > ^x("Bhaskar")="Sanchez" > ^x("Bhaskar",$C(3))=$C(5) > ^x("Bhaskar","Sanchez")="Malvern, Pennsylvania, USA" > ^x("Emiliano")="Iris Advies" > GTM> > > As you can see, the same variable (^x) has a scalar value, an array > element with one index, array elements with multiple indices, array > elements that are binary data $c(3) is a control-C, etc. The closest > analogs to M variables are awk arrays and Snobol4 tables. Database > accesses are just like array accesses, except that they are shared (if > one process sets it, another can read it), and persistence (if you shut > down the computer and come back tomorrow, it's still there). Of > course, there is support for full ACID transactions. Get a book by > Richard Walters called M Programming: A Comprehensive Guide to learn > more, or just download GT.M, read the manuals, and start playing. Have done, and will do. The above looks pretty much like what I've been looking for. I've also been looking at FramerD, which offers some similar concepts, but uses lisp. I'm not big on lisp. > > Could socket access be used to make blobs available via the database? > > [KSB] Absolutely! OK, the weekend will be spent reading manuals I guess. Thanks for your replies. Emile |
From: Terry W. <twi...@es...> - 2000-11-21 01:03:19
|
More specifically, we're building a content management system, and what we want is a loose hierarchy of free-form objects where it's possible (and easy, preferably) to add properties (fields, blobs) to objects at runtime. It should be possible to get a object description (what fields/what type) given an object. Objects could be as lightweight as appointment records (just a date + people involved in a simple case) or entire binary documents. On a scale from "you can do that" to "you're going to do _what_?!", where would you place using GT.M for this purpose? At the risk of overloading you totally, if your serious about a MUMPS solution you may want to look at EsiObjects. We've used MUMPS as an enabling technology to implement a robust object model based on Smalltalk, full TCP/IP Gateway, rich GUI development environment, etc. We don't support GT.M right now but plan to soon. Also, EsiObjects is going to Open Source once we release the next version. Terry L. Wiechmann |
From: Emiliano <em...@ir...> - 2000-11-21 07:28:18
|
Terry Wiechmann wrote: > At the risk of overloading you totally, if your serious about a MUMPS > solution you may want to look at EsiObjects. We've used MUMPS as an enabling > technology to implement a robust object model based on Smalltalk, full > TCP/IP Gateway, rich GUI development environment, etc. > > We don't support GT.M right now but plan to soon. Also, EsiObjects is going > to Open Source once we release the next version. Looks like a sweet product. How intimately tied to the Windows platform is it? Because our project is primarily Unix based. Emile |
From: Terry W. <twi...@es...> - 2000-11-21 12:53:39
|
Only the client development environment is Windows. The object implementation runs on ANSI MUMPS server side. That makes it independent of any OS. It currently runs on most MUMPS implementations. We hope to port it to GT.M as soon as it moves closer to the 95 ANSI standard. There is a 36 page white paper on it at http://www.esitechnology.com (under Library) if you are interested. Terry -----Original Message----- From: san...@li... [mailto:san...@li...]On Behalf Of Emiliano Sent: Tuesday, November 21, 2000 2:28 AM To: Terry Wiechmann Cc: san...@li... Subject: Re: [Sanchez-gtm-core] Application field Terry Wiechmann wrote: > At the risk of overloading you totally, if your serious about a MUMPS > solution you may want to look at EsiObjects. We've used MUMPS as an enabling > technology to implement a robust object model based on Smalltalk, full > TCP/IP Gateway, rich GUI development environment, etc. > > We don't support GT.M right now but plan to soon. Also, EsiObjects is going > to Open Source once we release the next version. Looks like a sweet product. How intimately tied to the Windows platform is it? Because our project is primarily Unix based. Emile _______________________________________________ Sanchez-gtm-core mailing list San...@li... http://lists.sourceforge.net/mailman/listinfo/sanchez-gtm-core |
From: Emiliano <em...@ir...> - 2000-12-04 22:37:34
|
Terry Wiechmann wrote: > > Only the client development environment is Windows. The object > implementation runs on ANSI MUMPS server side. That makes it independent of > any OS. It currently runs on most MUMPS implementations. We hope to port it > to GT.M as soon as it moves closer to the 95 ANSI standard. > > There is a 36 page white paper on it at http://www.esitechnology.com (under > Library) if you are interested. OK, I finally had (took) the time to read through this. Very, _very_ interesting. So whose arms must I twist to get this a) released, and b) to run on GT.M? A few questions left: will all of what I read in the whitepaper be released under the GPL? Including the CORBA and the ODMG bits? And does the latter include OQL? Those would be major enablers for me. And while we're on the topic: does Mumps have any native searching/indexing facilities? Or is Mumps more about persistance then datamining? How about data discovery? Do you have to know what's in a Mumps database to be able to access it, or can one discover format and content as I would be able to in an SQL database? I guess what I'm asking is, is meta-information available automatically? Emile |
From: Emiliano <em...@ir...> - 2000-12-13 19:43:44
|
OK, so I'm getting to grips with the fact that there isn't (or doesn't need to be) an active server-type application in a mumps installation. But who manages the transaction? How do two different Mumps programs know about each other? Disk-block locking? Emile |
From: K.S. B. <k.b...@sa...> - 2000-12-13 20:31:25
|
I have posted this from Emile, and my response in the Developers discussion forum on Source Forge. There is also a new document on GT.M security. -- Bhaskar On Wednesday, December 13, 2000 at 20:43:58 (GMT+0100), Emiliano wrote: > OK, so I'm getting to grips with the fact that there isn't (or doesn't > need to be) an active server-type application in a mumps installation. > > But who manages the transaction? How do two different Mumps programs > know about each other? Disk-block locking? > > Emile > _______________________________________________ > Sanchez-gtm-core mailing list > San...@li... > http://lists.sourceforge.net/mailman/listinfo/sanchez-gtm-core |
From: Emiliano <em...@ir...> - 2000-11-17 22:04:47
|
Thomas Good wrote: > > I'm in the process of comparing several databases in order to pick one > > for my project. Where would > > you guys say that the strong and wek points are of Sanchez? Where does > > it excel? And does it support > > BLOB storage? I couldn't find anything about it in the docs. > > > > That is a loaded question! Are you only interested in hierarchical > data storage or is something relational an option? In fact I'm _primarily_ interested in hierarchical storage. I've used SQL dtabases so far but maintaining inherently hierarchical data turned out to be a hassle. OK, so the hassle would probably have been less had I not inherited an MySQL 'solution', but still. So, is GT.M strong on hierarchies? What about those BLOBS? > I like GT.M so > far but it doesn't sport the wide variety of interfaces of some > relational databases, most notably my favourite: Postgres. > (Accessed via { Perl | Python | TCL/tk | JDBC | ODBC | C | PHP } ) No Perl access? Oh well, if there's a C interface it shouldn't be too hard. Emile |