Hello All,
PostgreSQL allows columns of a table to be defined as variable-length multidimensional arrays. Arrays of any built-in or user-defined base type can be created. In my application I have few object which are fairly flat, but some of their instVArs are Arrays of numbers I am about to start implementing the mapping between VW Array(s) and Array in the PostgreSQL. Before I actually start doing it, I decided to check with the community if anybody already done that? Are there any caveats in implementing that kind of type mappings? Any information is greatly appreciated. TIA --Mark Pirogovsky |
This isn't much of a useful answer, but I'd consider staying away from
those. I have yet to see a design that justifies the use of PostgreSQL Arrays outside of heavy duty statistical application domain and you're also going to have problems porting your application away from PostgreSQL if you need to do that one day. If you only want to store an array of numbers into a column, can't you simply use a blob (bytea) to store a boss of that array? Hope this helps, -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Mark Pirogovsky [mailto:[hidden email]] Sent: Monday, April 03, 2006 11:38 AM To: vwnc-list Cc: [hidden email] Subject: VW - PostgreSQL question Hello All, PostgreSQL allows columns of a table to be defined as variable-length multidimensional arrays. Arrays of any built-in or user-defined base type can be created. In my application I have few object which are fairly flat, but some of their instVArs are Arrays of numbers I am about to start implementing the mapping between VW Array(s) and Array in the PostgreSQL. Before I actually start doing it, I decided to check with the community if anybody already done that? Are there any caveats in implementing that kind of type mappings? Any information is greatly appreciated. TIA --Mark Pirogovsky smime.p7s (4K) Download Attachment |
In reply to this post by Mark Pirogovsky-3
Mark,
On 04/04/06, Mark Pirogovsky <[hidden email]> wrote: > PostgreSQL allows columns of a table to be defined as variable-length > multidimensional arrays. Arrays of any built-in or user-defined base > type can be created. I don't have a test using these structures in the PostgreSQL drivers, and I've never tried it myself but I'd be very interested in hearing how you get on. I would start by checking this out with just the driver library alone. Have a look at the class side of PostgreSQLTest and add tests that create, populate and query the structure you have in mind. Then try the same in PostgreSQLEXDITest. Please do publish any changes you make back to the public Store, or even just email a fileout to me - thanks. All the best, Bruce p.s. I would tend to agree with Boris and suggest that you start off with a normalised model (e.g. 1NF: no repeating groups) and only de-normalise if you have (e.g.) performance problems. -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
In reply to this post by Mark Pirogovsky-3
One example of such potential problem would be the speed of boss
reader/writer to convert your data from/to those byte arrays, which again may or may not be the problem depending on the size of your arrays, I certainly don't wish to encourage premature optimization, dbin := (1 to: 15 factorial by: 10000000) asArray. timein := Time millisecondsToRun: [ stream := ByteArray new writeStream. (BinaryObjectStorage onNew: stream) nextPut: dbin; close]. bytea := stream contents. timeout := Time millisecondsToRun: [ stream := ReadStream on: bytea. dbout := (BinaryObjectStorage onOldNoScan: stream) next]. dbout = dbin ifFalse: [self error: 'arrays do not match']. Transcript cr; show: 'write boss: ' , timein printString , ' milliseconds'. Transcript cr; show: 'read boss: ' , timeout printString , ' milliseconds'. which on my machine results in, write boss: 2421 milliseconds read boss: 6076 milliseconds Mind you that's fairly sizable array with 130,768 elements at 1,720,060 bytes in boss. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Bruce Badger [mailto:[hidden email]] Sent: Monday, April 03, 2006 1:49 PM To: Mark Pirogovsky Cc: vwnc-list; [hidden email] Subject: Re: VW - PostgreSQL question Mark, On 04/04/06, Mark Pirogovsky <[hidden email]> wrote: > PostgreSQL allows columns of a table to be defined as variable-length > multidimensional arrays. Arrays of any built-in or user-defined base > type can be created. I don't have a test using these structures in the PostgreSQL drivers, and I've never tried it myself but I'd be very interested in hearing how you get on. I would start by checking this out with just the driver library alone. Have a look at the class side of PostgreSQLTest and add tests that create, populate and query the structure you have in mind. Then try the same in PostgreSQLEXDITest. Please do publish any changes you make back to the public Store, or even just email a fileout to me - thanks. All the best, Bruce p.s. I would tend to agree with Boris and suggest that you start off with a normalised model (e.g. 1NF: no repeating groups) and only de-normalise if you have (e.g.) performance problems. -- Make the most of your skills - with OpenSkills http://www.openskills.org/ smime.p7s (4K) Download Attachment |
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris,
the thing I need to store -- is some kind of matrice, for the mahematical modeling. I don't see any better ways to normalize it then just store it as an array. I can of cource store the string representation of my arrays like in storeOn:aStream. Howevere on of the advatages of the PoostgreSQL array that I can use normal SQL queries to select all the functions where 5th and 7th elements are eqv. X like the following: select * from MyFunction where myArry[7] =0 and myArray[5]=0 if I use storeOn:, or BOSS I will lose that ability. AS far as portability is concerned, storing Array as an Array[] in postgesql, will work well in case if I decide later move to Gemstone for example. Actually any SQL:1999 compatible database should support it: "SQL:1999 also has two new composite types: ARRAY and ROW. The ARRAY type allows one to store collections of values directly in a column of a database table. For example: WEEKDAYS VARCHAR(10) ARRAY[7] would allow one to store the names of all seven weekdays directly in a single row in the database. Does this mean that SQL:1999 allows databases that do not satisfy first normal form? Indeed, it does, in the sense that it allows “repeating groups”, which first normal form prohibits. (However, some have argued that SQL:1999’s ARRAY type merely allows storage of information that can be decomposed, much as the SUBSTRING function can decompose character strings—and therefore doesn’t truly violate the spirit of first normal form.) The ROW type in SQL:1999 is an extension of the (anonymous) row type that SQL has always had and depended on having. It gives database designers the additional power of storing structured values in single columns of the database: CREATE TABLE employee ( EMP_ID INTEGER, NAME ROW ( GIVEN VARCHAR(30), FAMILY VARCHAR(30) ), ADDRESS ROW ( STREET VARCHAR(50), CITY VARCHAR(30), STATE CHAR(2) ) SALARY REAL ) SELECT E.NAME.FAMILY FROM employee E While you might argue that this also violates first normal form, most observers recognize it as just another “decomposable” data type". -Mark Boris Popov wrote: > This isn't much of a useful answer, but I'd consider staying away from > those. I have yet to see a design that justifies the use of PostgreSQL > Arrays outside of heavy duty statistical application domain and you're also > going to have problems porting your application away from PostgreSQL if you > need to do that one day. If you only want to store an array of numbers into > a column, can't you simply use a blob (bytea) to store a boss of that array? > > Hope this helps, > > -Boris > |
In reply to this post by Mark Pirogovsky-3
Fair enough, so long as there's a reasonable need for this feature. Don't be
fooled by the spec though, just because something is SQL99, doesn't mean PostgreSQL's interpretation will be compatible with other DBs. Let us know how your experiment with PostgreSQLEXDI goes. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Mark Pirogovsky [mailto:[hidden email]] Sent: Monday, April 03, 2006 9:00 PM To: Boris Popov Cc: vwnc-list; [hidden email] Subject: Re: VW - PostgreSQL question Boris, the thing I need to store -- is some kind of matrice, for the mahematical modeling. I don't see any better ways to normalize it then just store it as an array. I can of cource store the string representation of my arrays like in storeOn:aStream. Howevere on of the advatages of the PoostgreSQL array that I can use normal SQL queries to select all the functions where 5th and 7th elements are eqv. X like the following: select * from MyFunction where myArry[7] =0 and myArray[5]=0 if I use storeOn:, or BOSS I will lose that ability. AS far as portability is concerned, storing Array as an Array[] in postgesql, will work well in case if I decide later move to Gemstone for example. Actually any SQL:1999 compatible database should support it: "SQL:1999 also has two new composite types: ARRAY and ROW. The ARRAY type allows one to store collections of values directly in a column of a database table. For example: WEEKDAYS VARCHAR(10) ARRAY[7] would allow one to store the names of all seven weekdays directly in a single row in the database. Does this mean that SQL:1999 allows databases that do not satisfy first normal form? Indeed, it does, in the sense that it allows "repeating groups", which first normal form prohibits. (However, some have argued that SQL:1999's ARRAY type merely allows storage of information that can be decomposed, much as the SUBSTRING function can decompose character strings-and therefore doesn't truly violate the spirit of first normal form.) The ROW type in SQL:1999 is an extension of the (anonymous) row type that SQL has always had and depended on having. It gives database designers the additional power of storing structured values in single columns of the database: CREATE TABLE employee ( EMP_ID INTEGER, NAME ROW ( GIVEN VARCHAR(30), FAMILY VARCHAR(30) ), ADDRESS ROW ( STREET VARCHAR(50), CITY VARCHAR(30), STATE CHAR(2) ) SALARY REAL ) SELECT E.NAME.FAMILY FROM employee E While you might argue that this also violates first normal form, most observers recognize it as just another "decomposable" data type". -Mark Boris Popov wrote: > This isn't much of a useful answer, but I'd consider staying away from > those. I have yet to see a design that justifies the use of PostgreSQL > Arrays outside of heavy duty statistical application domain and you're also > going to have problems porting your application away from PostgreSQL if you > need to do that one day. If you only want to store an array of numbers into > a column, can't you simply use a blob (bytea) to store a boss of that array? > > Hope this helps, > > -Boris > smime.p7s (4K) Download Attachment |
In reply to this post by Mark Pirogovsky-3
I guess what you are saying is that your app is so simple that using
something like Glorp is not warranted? My philosophy nowdays is use: 1. Gemstone if possible 2. Use Glorp if not 3. Shoot yourself hth, -Charles On Mon, 03 Apr 2006 14:38:15 -0400, Mark Pirogovsky <[hidden email]> wrote: > Hello All, > > PostgreSQL allows columns of a table to be defined as variable-length > multidimensional arrays. Arrays of any built-in or user-defined base > type can be created. > > In my application I have few object which are fairly flat, but some of > their instVArs are Arrays of numbers > > I am about to start implementing the mapping between VW Array(s) and > Array in the PostgreSQL. > > Before I actually start doing it, I decided to check with the community > if anybody already done that? > Are there any caveats in implementing that kind of type mappings? > > Any information is greatly appreciated. > > TIA > > --Mark Pirogovsky -- Charles A. Monteiro |
In reply to this post by Mark Pirogovsky-3
My understanding is that its not about simplicity, but rather a requirement
to store matrices using multidimensional arrays within the database and that can't easily or efficiently be done otherwise. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Charles A. Monteiro [mailto:[hidden email]] Sent: Tuesday, April 04, 2006 5:52 AM To: Mark Pirogovsky; vwnc-list Cc: [hidden email] Subject: Re: VW - PostgreSQL question I guess what you are saying is that your app is so simple that using something like Glorp is not warranted? My philosophy nowdays is use: 1. Gemstone if possible 2. Use Glorp if not 3. Shoot yourself hth, -Charles On Mon, 03 Apr 2006 14:38:15 -0400, Mark Pirogovsky <[hidden email]> wrote: > Hello All, > > PostgreSQL allows columns of a table to be defined as variable-length > multidimensional arrays. Arrays of any built-in or user-defined base > type can be created. > > In my application I have few object which are fairly flat, but some of > their instVArs are Arrays of numbers > > I am about to start implementing the mapping between VW Array(s) and > Array in the PostgreSQL. > > Before I actually start doing it, I decided to check with the community > if anybody already done that? > Are there any caveats in implementing that kind of type mappings? > > Any information is greatly appreciated. > > TIA > > --Mark Pirogovsky -- Charles A. Monteiro smime.p7s (4K) Download Attachment |
Boris:
You may be right of course :) but This is all we know about Mark object model: Exhibit A > In my application I have few object which are fairly flat, but some of > their instVArs are Arrays of numbers This is what we know about his tentative implementation which I conveniently refuse to understand as requirements : Exhibit B > PostgreSQL allows columns of a table to be defined as variable-length > multidimensional arrays. Arrays of any built-in or user-defined base > type can be created. and: Exhibit B.2 > I am about to start implementing the mapping between VW Array(s) and > Array in the PostgreSQL. > Therefore if Glorp can't do Exhibit A we are hurting :) also given what Mark has said I think I have just as valid an interpretation :) finally since apparently Mark has not yet implemented anything I'm not positive that you can make any statements regarding efficiency i.e. such as: "but rather a requirement to store matrices using multidimensional arrays within the database and that can't easily or efficiently be done otherwise." Anyhow, Mark, I have changed my mind I now just recommend that you shoot yourself :) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Boris wrote: My understanding is that its not about simplicity, but rather a requirement to store matrices using multidimensional arrays within the database and that can't easily or efficiently be done otherwise. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Charles A. Monteiro [mailto:[hidden email]] Sent: Tuesday, April 04, 2006 5:52 AM To: Mark Pirogovsky; vwnc-list Cc: [hidden email] Subject: Re: VW - PostgreSQL question I guess what you are saying is that your app is so simple that using something like Glorp is not warranted? My philosophy nowdays is use: 1. Gemstone if possible 2. Use Glorp if not 3. Shoot yourself hth, -Charles On Mon, 03 Apr 2006 14:38:15 -0400, Mark Pirogovsky <[hidden email]> wrote: > Hello All, > > PostgreSQL allows columns of a table to be defined as variable-length > multidimensional arrays. Arrays of any built-in or user-defined base > type can be created. > > In my application I have few object which are fairly flat, but some of > their instVArs are Arrays of numbers > > I am about to start implementing the mapping between VW Array(s) and > Array in the PostgreSQL. > > Before I actually start doing it, I decided to check with the community > if anybody already done that? > Are there any caveats in implementing that kind of type mappings? > > Any information is greatly appreciated. > > TIA > > --Mark Pirogovsky -- Charles A. Monteiro |
In reply to this post by Mark Pirogovsky-3
Quote,
"the thing I need to store -- is some kind of matrice, for the mahematical modeling. I don't see any better ways to normalize it then just store it as an array. I can of cource store the string representation of my arrays like in storeOn:aStream. Howevere on of the advatages of the PoostgreSQL array that I can use normal SQL queries to select all the functions where 5th and 7th elements are eqv. X like the following: select * from MyFunction where myArry[7] = 0 and myArray[5] = 0" So its pretty clear what the intention of this one aspect is as far as I'm concerned. My first reaction was to suggest using BOSS to store these matrices in BLOBs, but obviously (extra overhead of conversion aside, see my previous email that evaluates boss read/write performance on larger arrays) this creates a model with zero querying capability, which may not be the problem for some applications, but it seems that Mark needs to search by looking inside the data. Also, with regards to your comment about Glorp, would you mind elaborating a bit on why you think we're hurting? Arrays of built-in types must first be supported by EXDIs, Glorp just rides the wave from there. If PostgreSQLEXDI gets this feature, adding new Glorp database type is trivial, but my brief Google search revealed little evidence to suggest that other backends support this SQL99 feature. It'd be great if they did, so if you know of any, let us know, I'm quite curious. Thanks! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Charles A. Monteiro [mailto:[hidden email]] Sent: Tuesday, April 04, 2006 7:00 AM To: Boris Popov; Mark Pirogovsky; vwnc-list Cc: [hidden email] Subject: Re: VW - PostgreSQL question Boris: You may be right of course :) but This is all we know about Mark object model: Exhibit A > In my application I have few object which are fairly flat, but some of > their instVArs are Arrays of numbers This is what we know about his tentative implementation which I conveniently refuse to understand as requirements : Exhibit B > PostgreSQL allows columns of a table to be defined as variable-length > multidimensional arrays. Arrays of any built-in or user-defined base > type can be created. and: Exhibit B.2 > I am about to start implementing the mapping between VW Array(s) and > Array in the PostgreSQL. > Therefore if Glorp can't do Exhibit A we are hurting :) also given what Mark has said I think I have just as valid an interpretation :) finally since apparently Mark has not yet implemented anything I'm not positive that you can make any statements regarding efficiency i.e. such as: "but rather a requirement to store matrices using multidimensional arrays within the database and that can't easily or efficiently be done otherwise." Anyhow, Mark, I have changed my mind I now just recommend that you shoot yourself :) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Boris wrote: My understanding is that its not about simplicity, but rather a requirement to store matrices using multidimensional arrays within the database and that can't easily or efficiently be done otherwise. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Charles A. Monteiro [mailto:[hidden email]] Sent: Tuesday, April 04, 2006 5:52 AM To: Mark Pirogovsky; vwnc-list Cc: [hidden email] Subject: Re: VW - PostgreSQL question I guess what you are saying is that your app is so simple that using something like Glorp is not warranted? My philosophy nowdays is use: 1. Gemstone if possible 2. Use Glorp if not 3. Shoot yourself hth, -Charles On Mon, 03 Apr 2006 14:38:15 -0400, Mark Pirogovsky <[hidden email]> wrote: > Hello All, > > PostgreSQL allows columns of a table to be defined as variable-length > multidimensional arrays. Arrays of any built-in or user-defined base > type can be created. > > In my application I have few object which are fairly flat, but some of > their instVArs are Arrays of numbers > > I am about to start implementing the mapping between VW Array(s) and > Array in the PostgreSQL. > > Before I actually start doing it, I decided to check with the community > if anybody already done that? > Are there any caveats in implementing that kind of type mappings? > > Any information is greatly appreciated. > > TIA > > --Mark Pirogovsky -- Charles A. Monteiro smime.p7s (4K) Download Attachment |
In reply to this post by Charles A. Monteiro-2
Charles,
Since shooting myself is not a good development option - as there will be no more development after :-(), and I see a great need to "go postal" after those proposals, I 'd rather "shoot the messenger" i.e. Charles - how about this for the recursion ? Seriously, Postgress limitation on arrays are: a. No nulls allowed b. they have to be homogeneous. the Syntax there is very simple either {a,b,c,...} or Array[a,b,c,.....]. I always can create a table to simulate my matrices, but it will be grossly inefficient in terms of storage and retrieval times. Another thing that those matrices are of arbitrary sizes... The Gemstone is not an option at least at this time. Come to think of it, allowing to store the complex objects like Row or Array in the field brings the PostgreSQL much closer to the OODB like Gemstone - in a way that I don't have to jump through the hoops to map Smalltalk objects to zillion tables and views and go thorough the process of disassembly/reassembly every time I hit the database. Glorp is a great tool, which helps you to automate the aforementioned process, but it does not eliminate it. My 2c. --Mark Charles A. Monteiro wrote: > Boris: > > You may be right of course :) but > > This is all we know about Mark object model: > > Exhibit A > >> In my application I have few object which are fairly flat, but some >> of their instVArs are Arrays of numbers > > > This is what we know about his tentative implementation which I > conveniently refuse to understand as requirements : > > Exhibit B > >> PostgreSQL allows columns of a table to be defined as variable-length >> multidimensional arrays. Arrays of any built-in or user-defined base >> type can be created. > > > and: > > Exhibit B.2 > >> I am about to start implementing the mapping between VW Array(s) and >> Array in the PostgreSQL. >> > > Therefore if Glorp can't do Exhibit A we are hurting :) > also given what Mark has said I think I have just as valid an > interpretation :) > > finally since apparently Mark has not yet implemented anything I'm not > positive that you can make any statements regarding efficiency i.e. > such as: > > "but rather a requirement > to store matrices using multidimensional arrays within the database and > that > can't easily or efficiently be done otherwise." > > Anyhow, Mark, I have changed my mind I now just recommend that you > shoot yourself :) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Boris wrote: > > My understanding is that its not about simplicity, but rather a requirement > to store matrices using multidimensional arrays within the database and > that > can't easily or efficiently be done otherwise. > > Cheers! > > -Boris > |
In reply to this post by Mark Pirogovsky-3
Lets just say I have careful reservations about excessive use of arrays
within the RBMS. I just don't want to see schemas with colors varchar(100) array[] whereas matrices look like good candidates to justify matrix integer array[] See the following article for a more comprehensive overview, http://www.wiscorp.com/great_news_relational_model_is_dead.pdf To add to all of this, it seems that SQL03 now adds support for "multiset" too, which is really an unordered array and should have been simply called "set" IMHO ;) http://www.sigmod.org/record/issues/0403/E.JimAndrew-standard.pdf Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Mark Pirogovsky [mailto:[hidden email]] Sent: Tuesday, April 04, 2006 7:37 AM To: Charles A. Monteiro Cc: vwnc-list Subject: Re: VW - PostgreSQL question Charles, Since shooting myself is not a good development option - as there will be no more development after :-(), and I see a great need to "go postal" after those proposals, I 'd rather "shoot the messenger" i.e. Charles - how about this for the recursion ? Seriously, Postgress limitation on arrays are: a. No nulls allowed b. they have to be homogeneous. the Syntax there is very simple either {a,b,c,...} or Array[a,b,c,.....]. I always can create a table to simulate my matrices, but it will be grossly inefficient in terms of storage and retrieval times. Another thing that those matrices are of arbitrary sizes... The Gemstone is not an option at least at this time. Come to think of it, allowing to store the complex objects like Row or Array in the field brings the PostgreSQL much closer to the OODB like Gemstone - in a way that I don't have to jump through the hoops to map Smalltalk objects to zillion tables and views and go thorough the process of disassembly/reassembly every time I hit the database. Glorp is a great tool, which helps you to automate the aforementioned process, but it does not eliminate it. My 2c. --Mark Charles A. Monteiro wrote: > Boris: > > You may be right of course :) but > > This is all we know about Mark object model: > > Exhibit A > >> In my application I have few object which are fairly flat, but some >> of their instVArs are Arrays of numbers > > > This is what we know about his tentative implementation which I > conveniently refuse to understand as requirements : > > Exhibit B > >> PostgreSQL allows columns of a table to be defined as variable-length >> multidimensional arrays. Arrays of any built-in or user-defined base >> type can be created. > > > and: > > Exhibit B.2 > >> I am about to start implementing the mapping between VW Array(s) and >> Array in the PostgreSQL. >> > > Therefore if Glorp can't do Exhibit A we are hurting :) > also given what Mark has said I think I have just as valid an > interpretation :) > > finally since apparently Mark has not yet implemented anything I'm not > positive that you can make any statements regarding efficiency i.e. > such as: > > "but rather a requirement > to store matrices using multidimensional arrays within the database and > that > can't easily or efficiently be done otherwise." > > Anyhow, Mark, I have changed my mind I now just recommend that you > shoot yourself :) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Boris wrote: > > My understanding is that its not about simplicity, but rather a > to store matrices using multidimensional arrays within the database and > that > can't easily or efficiently be done otherwise. > > Cheers! > > -Boris > smime.p7s (4K) Download Attachment |
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Mark's second email got crossed in my email i.e. I did not see the second
email which you quote. > Also, with regards to your comment about Glorp, would you mind > elaborating a > bit on why you think we're hurting? i.e. given that I had not seen the second email then I was directly commenting about Mark's statement: "In my application I have few object which are fairly flat, but some of their instVArs are Arrays of numbers" and therefore my comment was that an OR layer should be able to support the mapping of an instVar to an array/collection of numbers which I am sure that it does i.e. GLORP or does it?. Obviously, given Mark's subsequent email that is actually not what he wants anyhow. Of course, I'm not being helpful at all :), I guess that after years of working with Gemstone and especially now that I have to work with the likes of Oracle , RDMS technology just rub me the wrong way. Also it seems that more emails that actually get to me in time :) i.e. for this thread that Gemstone would be a good fit. I understand that they now have small deployment licences on Linux ranging in U.S. 5,000.00 range. They also of course have a non-commercial license which can take one a long way. I guess Gemstone still suffers from the stigma of being associated with the mega bucks ? I would not have the stamina to do what Mark wants with an RDMS :) -Charles On Tue, 04 Apr 2006 10:16:14 -0400, Boris Popov <[hidden email]> wrote: > Quote, > > "the thing I need to store -- is some kind of matrice, for the > mahematical modeling. I don't see any better ways to normalize it then > just store it as an array. I can of cource store the string > representation of my arrays like in storeOn:aStream. Howevere on of the > advatages of the PoostgreSQL array that I can use normal SQL queries to > select all the functions where 5th and 7th elements are eqv. X > like the following: > > select * from MyFunction where myArry[7] = 0 and myArray[5] = 0" > > So its pretty clear what the intention of this one aspect is as far as > I'm > concerned. My first reaction was to suggest using BOSS to store these > matrices in BLOBs, but obviously (extra overhead of conversion aside, > see my > previous email that evaluates boss read/write performance on larger > arrays) > this creates a model with zero querying capability, which may not be the > problem for some applications, but it seems that Mark needs to search by > looking inside the data. > > Also, with regards to your comment about Glorp, would you mind > elaborating a > bit on why you think we're hurting? Arrays of built-in types must first > be > supported by EXDIs, Glorp just rides the wave from there. If > PostgreSQLEXDI > gets this feature, adding new Glorp database type is trivial, but my > brief > Google search revealed little evidence to suggest that other backends > support this SQL99 feature. It'd be great if they did, so if you know of > any, let us know, I'm quite curious. > > Thanks! > > -Boris > -- Charles A. Monteiro |
In reply to this post by Mark Pirogovsky-3
Charles, $5,000 is big bucks to a startup that's operating on a
shoestring. > -----Original Message----- > From: Charles A. Monteiro [mailto:[hidden email]] > Sent: Tuesday, April 04, 2006 10:59 AM > To: Boris Popov; Mark Pirogovsky; vwnc-list > Cc: [hidden email] > Subject: Re: VW - PostgreSQL question > > Mark's second email got crossed in my email i.e. I did not > see the second email which you quote. > > > > Also, with regards to your comment about Glorp, would you mind > > elaborating a bit on why you think we're hurting? > > i.e. given that I had not seen the second email then I was > directly commenting about Mark's statement: > > "In my application I have few object which are fairly flat, > but some of their instVArs are Arrays of numbers" > > and therefore my comment was that an OR layer should be able > to support the mapping of an instVar to an array/collection > of numbers which I am sure that it does i.e. GLORP or does > it?. Obviously, given Mark's subsequent email that is > actually not what he wants anyhow. > > Of course, I'm not being helpful at all :), I guess that > after years of working with Gemstone and especially now that > I have to work with the likes of Oracle , RDMS technology > just rub me the wrong way. > > Also it seems that more emails that actually get to me in > time :) i.e. for this thread that Gemstone would be a good > fit. I understand that they now have small deployment > licences on Linux ranging in U.S. 5,000.00 range. > They also of course have a non-commercial license which can > take one a long way. I guess Gemstone still suffers from the > stigma of being associated with the mega bucks ? > > I would not have the stamina to do what Mark wants with an RDMS :) > > -Charles > > > > > On Tue, 04 Apr 2006 10:16:14 -0400, Boris Popov > <[hidden email]> > wrote: > > > Quote, > > > > "the thing I need to store -- is some kind of matrice, for the > > mahematical modeling. I don't see any better ways to normalize it > > then just store it as an array. I can of cource store the string > > representation of my arrays like in storeOn:aStream. > Howevere on of > > the advatages of the PoostgreSQL array that I can use normal SQL > > queries to select all the functions where 5th and 7th elements are > > eqv. X like the following: > > > > select * from MyFunction where myArry[7] = 0 and myArray[5] = 0" > > > > So its pretty clear what the intention of this one aspect > is as far as > > I'm concerned. My first reaction was to suggest using BOSS to store > > these matrices in BLOBs, but obviously (extra overhead of > conversion > > aside, see my previous email that evaluates boss read/write > > performance on larger > > arrays) > > this creates a model with zero querying capability, which > may not be > > the problem for some applications, but it seems that Mark needs to > > search by looking inside the data. > > > > Also, with regards to your comment about Glorp, would you mind > > elaborating a bit on why you think we're hurting? Arrays of > built-in > > types must first be supported by EXDIs, Glorp just rides > the wave from > > there. If PostgreSQLEXDI gets this feature, adding new > Glorp database > > type is trivial, but my brief Google search revealed little > evidence > > to suggest that other backends support this SQL99 feature. It'd be > > great if they did, so if you know of any, let us know, I'm quite > > curious. > > > > Thanks! > > > > -Boris > > > > > > -- > Charles A. Monteiro > > NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. |
In reply to this post by Mark Pirogovsky-3
Mark:
If you show up to one of our meetings I will allow you the chance to shoot me , well as long as you give me a running chance :), alternatively I will buy you some drinks it's up to you. See my incoming mail into the thread, my provider seems to be slow, my comments boil down to why not use Gemstone? GLORP is just a fallback but still worlds away. The latest advancements in Gemstone were almost mind blowing (Gemstone presented back in Feb) and the cost you can get it for make it a viable alternative. -Charles On Tue, 04 Apr 2006 10:37:15 -0400, Mark Pirogovsky <[hidden email]> wrote: > Charles, > Since shooting myself is not a good development option - as there will > be no more development after :-(), and I see a great need to "go postal" > after those proposals, I 'd rather "shoot the messenger" i.e. Charles - > how about this for the recursion ? > > Seriously, > > Postgress limitation on arrays are: > a. No nulls allowed > b. they have to be homogeneous. > > the Syntax there is very simple either {a,b,c,...} or Array[a,b,c,.....]. > > I always can create a table to simulate my matrices, but it will be > grossly inefficient in terms of storage and retrieval times. Another > thing that those matrices are of arbitrary sizes... > The Gemstone is not an option at least at this time. > > Come to think of it, allowing to store the complex objects like Row or > Array in the field brings the PostgreSQL much closer to the OODB like > Gemstone - in a way that I don't have to jump through the hoops to map > Smalltalk objects to zillion tables and views and go thorough the > process of disassembly/reassembly every time I hit the database. > > Glorp is a great tool, which helps you to automate the aforementioned > process, but it does not eliminate it. > > My 2c. > > --Mark > > Charles A. Monteiro wrote: > >> Boris: >> You may be right of course :) but >> This is all we know about Mark object model: >> Exhibit A >> >>> In my application I have few object which are fairly flat, but some >>> of their instVArs are Arrays of numbers >> This is what we know about his tentative implementation which I >> conveniently refuse to understand as requirements : >> Exhibit B >> >>> PostgreSQL allows columns of a table to be defined as variable-length >>> multidimensional arrays. Arrays of any built-in or user-defined base >>> type can be created. >> and: >> Exhibit B.2 >> >>> I am about to start implementing the mapping between VW Array(s) and >>> Array in the PostgreSQL. >>> >> Therefore if Glorp can't do Exhibit A we are hurting :) >> also given what Mark has said I think I have just as valid an >> interpretation :) >> finally since apparently Mark has not yet implemented anything I'm >> not positive that you can make any statements regarding efficiency >> i.e. such as: >> "but rather a requirement >> to store matrices using multidimensional arrays within the database >> and that >> can't easily or efficiently be done otherwise." >> Anyhow, Mark, I have changed my mind I now just recommend that you >> shoot yourself :) >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Boris wrote: >> My understanding is that its not about simplicity, but rather a >> requirement >> to store matrices using multidimensional arrays within the database >> and that >> can't easily or efficiently be done otherwise. >> Cheers! >> -Boris >> -- Charles A. Monteiro |
In reply to this post by Mark Pirogovsky-3
In order to understand how much Glorp supports you have to think about SQL92
and lack of built-in arrays :) So if you wanted to store an array of numbers, you'd either have to BOSS it into a BLOB or create separate records for those numbers and do something along the lines of, aDescriptor addMapping: ((OneToManyMapping new) attributeName: #numbers; referenceClass: GlorpNumber; collectionType: Array; orderBy: [:each | (each getTable: self numberTable) getField: 'ARRAY_POSITION']; writeTheOrderField; join: (Join from: (self ownerTable fieldNamed: 'ID') to: (self numberTable fieldNamed: 'ARRAY_OWNER'))). Lets just say its slightly easier to do in GemStone, but that's a rant for another day and there *are* advantages to using SQL even though I've used GemStone for years ;) Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Charles A. Monteiro [mailto:[hidden email]] Sent: Tuesday, April 04, 2006 7:59 AM To: Boris Popov; Mark Pirogovsky; vwnc-list Cc: [hidden email] Subject: Re: VW - PostgreSQL question Mark's second email got crossed in my email i.e. I did not see the second email which you quote. > Also, with regards to your comment about Glorp, would you mind > elaborating a > bit on why you think we're hurting? i.e. given that I had not seen the second email then I was directly commenting about Mark's statement: "In my application I have few object which are fairly flat, but some of their instVArs are Arrays of numbers" and therefore my comment was that an OR layer should be able to support the mapping of an instVar to an array/collection of numbers which I am sure that it does i.e. GLORP or does it?. Obviously, given Mark's subsequent email that is actually not what he wants anyhow. Of course, I'm not being helpful at all :), I guess that after years of working with Gemstone and especially now that I have to work with the likes of Oracle , RDMS technology just rub me the wrong way. Also it seems that more emails that actually get to me in time :) i.e. for this thread that Gemstone would be a good fit. I understand that they now have small deployment licences on Linux ranging in U.S. 5,000.00 range. They also of course have a non-commercial license which can take one a long way. I guess Gemstone still suffers from the stigma of being associated with the mega bucks ? I would not have the stamina to do what Mark wants with an RDMS :) -Charles On Tue, 04 Apr 2006 10:16:14 -0400, Boris Popov <[hidden email]> wrote: > Quote, > > "the thing I need to store -- is some kind of matrice, for the > mahematical modeling. I don't see any better ways to normalize it then > just store it as an array. I can of cource store the string > representation of my arrays like in storeOn:aStream. Howevere on of the > advatages of the PoostgreSQL array that I can use normal SQL queries to > select all the functions where 5th and 7th elements are eqv. X > like the following: > > select * from MyFunction where myArry[7] = 0 and myArray[5] = 0" > > So its pretty clear what the intention of this one aspect is as far as > I'm > concerned. My first reaction was to suggest using BOSS to store these > matrices in BLOBs, but obviously (extra overhead of conversion aside, > see my > previous email that evaluates boss read/write performance on larger > arrays) > this creates a model with zero querying capability, which may not be the > problem for some applications, but it seems that Mark needs to search by > looking inside the data. > > Also, with regards to your comment about Glorp, would you mind > elaborating a > bit on why you think we're hurting? Arrays of built-in types must first > be > supported by EXDIs, Glorp just rides the wave from there. If > PostgreSQLEXDI > gets this feature, adding new Glorp database type is trivial, but my > brief > Google search revealed little evidence to suggest that other backends > support this SQL99 feature. It'd be great if they did, so if you know of > any, let us know, I'm quite curious. > > Thanks! > > -Boris > -- Charles A. Monteiro smime.p7s (4K) Download Attachment |
In reply to this post by Sattler, Thomas (IT)
no its not :) not by most real definitions of a startup :)
start-ups get VC , small business loan etc i.e. Do you know how much it cost to buy a industrial strength capuccino machine? well I'll tell you because the old lady where I sometimes go for expresso told me , it cost her about $3,000.00 not to mention all the other stuff she needs to run her bakery. I will agree that if you are Joe developer trying to run something on the cheap from home that it may not work but perhaps that is something that one needs to approach the Gemstone Smalltalk business development manager :) secondly, you can basically do all of your development on a NC license so development costs can be minimal, then if you have a real product then you must sell your idea and get somebody to give you money. It will cost you more money and aggravation to do somethings with an RDMS if you have a bad fit. For somethings Postgres will just do ok in which case I would try using GLORP. -Charles On Tue, 04 Apr 2006 10:58:15 -0400, Sattler, Thomas (IT) <[hidden email]> wrote: > Charles, $5,000 is big bucks to a startup that's operating on a > shoestring. > > >> -----Original Message----- >> From: Charles A. Monteiro [mailto:[hidden email]] >> Sent: Tuesday, April 04, 2006 10:59 AM >> To: Boris Popov; Mark Pirogovsky; vwnc-list >> Cc: [hidden email] >> Subject: Re: VW - PostgreSQL question >> >> Mark's second email got crossed in my email i.e. I did not >> see the second email which you quote. >> >> >> > Also, with regards to your comment about Glorp, would you mind >> > elaborating a bit on why you think we're hurting? >> >> i.e. given that I had not seen the second email then I was >> directly commenting about Mark's statement: >> >> "In my application I have few object which are fairly flat, >> but some of their instVArs are Arrays of numbers" >> >> and therefore my comment was that an OR layer should be able >> to support the mapping of an instVar to an array/collection >> of numbers which I am sure that it does i.e. GLORP or does >> it?. Obviously, given Mark's subsequent email that is >> actually not what he wants anyhow. >> >> Of course, I'm not being helpful at all :), I guess that >> after years of working with Gemstone and especially now that >> I have to work with the likes of Oracle , RDMS technology >> just rub me the wrong way. >> >> Also it seems that more emails that actually get to me in >> time :) i.e. for this thread that Gemstone would be a good >> fit. I understand that they now have small deployment >> licences on Linux ranging in U.S. 5,000.00 range. >> They also of course have a non-commercial license which can >> take one a long way. I guess Gemstone still suffers from the >> stigma of being associated with the mega bucks ? >> >> I would not have the stamina to do what Mark wants with an RDMS :) >> >> -Charles >> >> >> >> >> On Tue, 04 Apr 2006 10:16:14 -0400, Boris Popov >> <[hidden email]> >> wrote: >> >> > Quote, >> > >> > "the thing I need to store -- is some kind of matrice, for the >> > mahematical modeling. I don't see any better ways to normalize it >> > then just store it as an array. I can of cource store the string >> > representation of my arrays like in storeOn:aStream. >> Howevere on of >> > the advatages of the PoostgreSQL array that I can use normal SQL >> > queries to select all the functions where 5th and 7th elements are >> > eqv. X like the following: >> > >> > select * from MyFunction where myArry[7] = 0 and myArray[5] = 0" >> > >> > So its pretty clear what the intention of this one aspect >> is as far as >> > I'm concerned. My first reaction was to suggest using BOSS to store >> > these matrices in BLOBs, but obviously (extra overhead of >> conversion >> > aside, see my previous email that evaluates boss read/write >> > performance on larger >> > arrays) >> > this creates a model with zero querying capability, which >> may not be >> > the problem for some applications, but it seems that Mark needs to >> > search by looking inside the data. >> > >> > Also, with regards to your comment about Glorp, would you mind >> > elaborating a bit on why you think we're hurting? Arrays of >> built-in >> > types must first be supported by EXDIs, Glorp just rides >> the wave from >> > there. If PostgreSQLEXDI gets this feature, adding new >> Glorp database >> > type is trivial, but my brief Google search revealed little >> evidence >> > to suggest that other backends support this SQL99 feature. It'd be >> > great if they did, so if you know of any, let us know, I'm quite >> > curious. >> > >> > Thanks! >> > >> > -Boris >> > >> >> >> >> -- >> Charles A. Monteiro >> >> > -------------------------------------------------------- > > NOTICE: If received in error, please destroy and notify sender. Sender > does not waive confidentiality or privilege, and use is prohibited. -- Charles A. Monteiro |
In reply to this post by Mark Pirogovsky-3
.. must .. resist .. getting .. involved ..
There are *many* more aspects to owning a DB aside from the initial investment, and DBA is only one of them. We have trouble finding Smalltalk developers for hire as it is, I can only imagine what the response would be if we had tried to find an experienced GemStone DBA today :) Like I said before, I absolutely love GemStone and enjoyed my time working with it and would love to discuss this in detail, but doing it on the mailing list may not be the most effective way to go as things could quickly get out of control. Is there a GemStone BOF scheduled at STS'06? Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Charles A. Monteiro [mailto:[hidden email]] Sent: Tuesday, April 04, 2006 8:15 AM To: Sattler, Thomas (IT); Boris Popov; Mark Pirogovsky; vwnc-list Cc: [hidden email] Subject: Re: VW - PostgreSQL question no its not :) not by most real definitions of a startup :) start-ups get VC , small business loan etc i.e. Do you know how much it cost to buy a industrial strength capuccino machine? well I'll tell you because the old lady where I sometimes go for expresso told me , it cost her about $3,000.00 not to mention all the other stuff she needs to run her bakery. I will agree that if you are Joe developer trying to run something on the cheap from home that it may not work but perhaps that is something that one needs to approach the Gemstone Smalltalk business development manager :) secondly, you can basically do all of your development on a NC license so development costs can be minimal, then if you have a real product then you must sell your idea and get somebody to give you money. It will cost you more money and aggravation to do somethings with an RDMS if you have a bad fit. For somethings Postgres will just do ok in which case I would try using GLORP. -Charles On Tue, 04 Apr 2006 10:58:15 -0400, Sattler, Thomas (IT) <[hidden email]> wrote: > Charles, $5,000 is big bucks to a startup that's operating on a > shoestring. > > >> -----Original Message----- >> From: Charles A. Monteiro [mailto:[hidden email]] >> Sent: Tuesday, April 04, 2006 10:59 AM >> To: Boris Popov; Mark Pirogovsky; vwnc-list >> Cc: [hidden email] >> Subject: Re: VW - PostgreSQL question >> >> Mark's second email got crossed in my email i.e. I did not >> see the second email which you quote. >> >> >> > Also, with regards to your comment about Glorp, would you mind >> > elaborating a bit on why you think we're hurting? >> >> i.e. given that I had not seen the second email then I was >> directly commenting about Mark's statement: >> >> "In my application I have few object which are fairly flat, >> but some of their instVArs are Arrays of numbers" >> >> and therefore my comment was that an OR layer should be able >> to support the mapping of an instVar to an array/collection >> of numbers which I am sure that it does i.e. GLORP or does >> it?. Obviously, given Mark's subsequent email that is >> actually not what he wants anyhow. >> >> Of course, I'm not being helpful at all :), I guess that >> after years of working with Gemstone and especially now that >> I have to work with the likes of Oracle , RDMS technology >> just rub me the wrong way. >> >> Also it seems that more emails that actually get to me in >> time :) i.e. for this thread that Gemstone would be a good >> fit. I understand that they now have small deployment >> licences on Linux ranging in U.S. 5,000.00 range. >> They also of course have a non-commercial license which can >> take one a long way. I guess Gemstone still suffers from the >> stigma of being associated with the mega bucks ? >> >> I would not have the stamina to do what Mark wants with an RDMS :) >> >> -Charles >> >> >> >> >> On Tue, 04 Apr 2006 10:16:14 -0400, Boris Popov >> <[hidden email]> >> wrote: >> >> > Quote, >> > >> > "the thing I need to store -- is some kind of matrice, for the >> > mahematical modeling. I don't see any better ways to normalize it >> > then just store it as an array. I can of cource store the string >> > representation of my arrays like in storeOn:aStream. >> Howevere on of >> > the advatages of the PoostgreSQL array that I can use normal SQL >> > queries to select all the functions where 5th and 7th elements are >> > eqv. X like the following: >> > >> > select * from MyFunction where myArry[7] = 0 and myArray[5] = 0" >> > >> > So its pretty clear what the intention of this one aspect >> is as far as >> > I'm concerned. My first reaction was to suggest using BOSS to store >> > these matrices in BLOBs, but obviously (extra overhead of >> conversion >> > aside, see my previous email that evaluates boss read/write >> > performance on larger >> > arrays) >> > this creates a model with zero querying capability, which >> may not be >> > the problem for some applications, but it seems that Mark needs to >> > search by looking inside the data. >> > >> > Also, with regards to your comment about Glorp, would you mind >> > elaborating a bit on why you think we're hurting? Arrays of >> built-in >> > types must first be supported by EXDIs, Glorp just rides >> the wave from >> > there. If PostgreSQLEXDI gets this feature, adding new >> Glorp database >> > type is trivial, but my brief Google search revealed little >> evidence >> > to suggest that other backends support this SQL99 feature. It'd be >> > great if they did, so if you know of any, let us know, I'm quite >> > curious. >> > >> > Thanks! >> > >> > -Boris >> > >> >> >> >> -- >> Charles A. Monteiro >> >> > -------------------------------------------------------- > > NOTICE: If received in error, please destroy and notify sender. Sender > does not waive confidentiality or privilege, and use is prohibited. -- Charles A. Monteiro smime.p7s (4K) Download Attachment |
In reply to this post by Charles A. Monteiro-2
>----- Original Message -----
>From: Boris Popov >We have trouble finding Smalltalk
>developers for hire as it is, I can only imagine what the response would be >if we had tried to find an experienced GemStone DBA today :) Have you considered hiring good Java programmers who would like to learn
Smalltalk? I bet they'd take to it pretty well. ;-)
-Carl Gundel, author of Liberty BASIC
|
In reply to this post by Mark Pirogovsky-3
How do you find those though? ;)
-Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Carl Gundel [mailto:[hidden email]] Sent: Tuesday, April 04, 2006 8:32 AM To: vwnc-list Subject: Re: VW - PostgreSQL question >----- Original Message ----- >From: Boris Popov >We have trouble finding Smalltalk >developers for hire as it is, I can only imagine what the response would be >if we had tried to find an experienced GemStone DBA today :) Have you considered hiring good Java programmers who would like to learn Smalltalk? I bet they'd take to it pretty well. ;-) -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com smime.p7s (4K) Download Attachment |
Free forum by Nabble | Edit this page |