[29142] in Perl-Users-Digest
Perl-Users Digest, Issue: 386 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Apr 27 03:14:21 2007
Date: Fri, 27 Apr 2007 00:14:11 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 27 Apr 2007 Volume: 11 Number: 386
Today's topics:
Re: Readable/writable database in Perl <ecarlson@vmware.com>
Re: Readable/writable database in Perl <spamtrap@dot-app.org>
Re: Readable/writable database in Perl <spamtrap@dot-app.org>
Re: Readable/writable database in Perl <ecarlson@vmware.com>
Re: Readable/writable database in Perl xhoster@gmail.com
Re: Readable/writable database in Perl <uri@stemsystems.com>
Re: Readable/writable database in Perl <joe@inwap.com>
Re: Readable/writable database in Perl <joe@inwap.com>
Re: SQL statement in Perl doesn't work <nobull67@gmail.com>
Re: SQL statement in Perl doesn't work <nobull67@gmail.com>
Re: STDOUT redirection <klaus03@gmail.com>
Re: STDOUT redirection <tadmc@augustmail.com>
Re: UTF8 European characters in MySQL <check.sig@for.email.invalid>
video lectures on C, C++, Java, Python and other progr <Arao44@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 26 Apr 2007 15:57:44 -0700
From: Eric <ecarlson@vmware.com>
Subject: Re: Readable/writable database in Perl
Message-Id: <1177628263.952707.177890@c18g2000prb.googlegroups.com>
Thanks for this direction, Brian. I will certainly look into this.
Eric
Brian McCauley wrote:
> On Apr 26, 6:08 pm, Eric <ecarl...@vmware.com> wrote:
> > Currently, our code is utilizing a database that is neither humanly
> > readable or writable. My task is to modify the existing code so that
> > the database is both.
>
> > I'm not looking for the solution in the posting (that wouldn't be any
> > fun :); what I am looking for is some initial direction on how I might
> > go about accomplishing this. There are no shortage of database related
> > core and CPAN modules. In particular, I was told to use the 'mySQL'
> > approach (if that means anything to anybody).
>
> Well, if you want to use a human readable database you'd do better to
> use a database module that uses flat files, like say DBD::CSV or
> DBD::AnyData.
------------------------------
Date: Thu, 26 Apr 2007 19:08:17 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Readable/writable database in Perl
Message-Id: <m2hcr2pwda.fsf@local.wv-www.com>
Eric <ecarlson@vmware.com> writes:
> Xho,
>
> Thanks for your reply to my posting. My response inline:
That's the normal way of writing responses. No need to point it out. :-)
>> If you want us to ignore code, then you should remove before you post it,
>> rather than just posting it and asking us to ignore it.
>
> In the past I have been criticized for posting to this group without
> including all of the code. Seems like when I leave something out or
> try to simplify things, people seem to focus on that rather than the
> question I am asking. So I can't seem to win with that one.
Sure you can. If you were criticized in the past, it was for not including
all of the code that was *relevant to your question*. That often means you
need to write a separate, stand-alone test script that illustrates whatever
problem you're having, but isn't loaded down with a bunch of other code,
and that's a good thing!
In the process of weeding out what's relevant and writing the test script,
you'll often find that you've solved the problem yourself. So it's not just
a matter of appeasing a cranky group, it's a good habit that will help you
become a better, more self-sufficient programmer.
>> MySQL does not use human readable or writable data files. Well, unless you
>> are an extraordinarily gifted human.
>
> That's good information. Perhaps the person giving me this direction
> is unaware of this and we need to go a different route.
That depends on what they mean by "human readable."
MySQL's data files are not, by themselves, very readable. But, it does provide
a generic interface. So, other programs can be written that use the same data,
or the "raw" SQL interface can be used to run ad-hoc queries. So it's human
readable in the sense that this one particular program you're writing won't
be the only way to work with the data.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Thu, 26 Apr 2007 19:09:50 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Readable/writable database in Perl
Message-Id: <m2d51qpwap.fsf@local.wv-www.com>
Eric <ecarlson@vmware.com> writes:
Upside-down - please don't do that! English reads from top to bottom.
> Brian McCauley wrote:
>>
>> Well, if you want to use a human readable database you'd do better to
>> use a database module that uses flat files, like say DBD::CSV or
>> DBD::AnyData.
>
> Thanks for this direction, Brian. I will certainly look into this.
Replies belong below the quoted text, like this.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: 26 Apr 2007 16:20:21 -0700
From: Eric <ecarlson@vmware.com>
Subject: Re: Readable/writable database in Perl
Message-Id: <1177629620.905307.205210@o40g2000prh.googlegroups.com>
Sherm Pendley wrote:
> Eric <ecarlson@vmware.com> writes:
>
> Upside-down - please don't do that! English reads from top to bottom.
>
> > Brian McCauley wrote:
> >>
> >> Well, if you want to use a human readable database you'd do better to
> >> use a database module that uses flat files, like say DBD::CSV or
> >> DBD::AnyData.
> >
> > Thanks for this direction, Brian. I will certainly look into this.
>
> Replies belong below the quoted text, like this.
>
> sherm--
>
Unless you're replying to an email, in which case the reply text goes
at the top before the replied to text. :)
Eric
------------------------------
Date: 26 Apr 2007 23:22:41 GMT
From: xhoster@gmail.com
Subject: Re: Readable/writable database in Perl
Message-Id: <20070426192244.702$M8@newsreader.com>
Eric <ecarlson@vmware.com> wrote:
> Xho,
>
> Thanks for your reply to my posting. My response inline:
>
> > There is are good reasons that no "real" databases use human readable
> > and even more so, human writable) data files.
>
> I'm no expert in databases, period. But I did point out to my group
> that allowing someone to edit a database might corrupt it. I am only
> following instructions on this one.
>
> > What features of real databases are you willing to surrender to
> > accomplish this aim? Concurrency? Isolation? Atomicity? Durability?
> > Performance scalability with increasing database size? All of the
> > above?
>
> As stated, I am not an expert in databases. So I don't know what we
> are willing to give up. Having said that however, the database is will
> never grow to great bounds. So I don't think we'd be sacrificing a
> whole lot.
Then something that reads the entire file in and writes the entire file
back out when done, like Config::Simple, might be a good option. Or just
using Data::Dumper as a serializer, if the humans who will be reading it
are Perl people and like that Perlish format for data.
>
> > If you want us to ignore code, then you should remove before you post
> > it, rather than just posting it and asking us to ignore it.
>
> In the past I have been criticized for posting to this group without
> including all of the code. Seems like when I leave something out or
> try to simplify things, people seem to focus on that rather than the
> question I am asking. So I can't seem to win with that one.
The keys is that while the code you post should be "real" in the sense
that it can be run and in doing so it demonstrates the issues at hand, it
doesn't need to be identical to the end-goal code you are working on. Make
a reduced copy of the code that gets rid of all the stuff that you are
confident is irrelevant to the topic at hand. I do that not just for
posting, but also for my own testing purposes.
>
> > MySQL does not use human readable or writable data files. Well, unless
> > you are an extraordinarily gifted human.
>
> That's good information. Perhaps the person giving me this direction
> is unaware of this and we need to go a different route.
>
> > Sure. Step one, specify exactly what the task is, including the
> > answers to the questions I asked above about you are willing to
> > sacrifice.
>
> The task is to have a humanly readable/writable database. I don't know
> what we'd be willing to sacrifice, but as mentioned already, the
> database will be small by database standards.
You need to figure this out. The fact that it will be small mitigates
indexing/performance problems--you can just read and parse the whole thing
and then write out the whole thing each time. But it does little to
address the concurrency, atomicity, durability issues. You (or your boss,
since it seems you are mostly just following orders) absolutely must get a
handle on these things. Assuming the entire file will be re-written upon
any changes, then you need to figure out how to lock the file against one
Perl program accessing it while other Perl programs also accessing it,
between Perl and people accessing, and between people and other people
accessing. Will people change the file only while the program is quescient
or not running at all, or will they change it at any time? How will the
program know a change has been made, and how will it respond? If a human
is holding a lock for a long time, what should the program do? (presumably
the programs won't need to hold locks for extended period, so that
shouldn't be as much as an issue the other way around.)
>
> If we can't have what we want in a database, then I was told that we
> could create simple text files instead.
That is almost by definition what you will need to do. While it might be
possible to build some fancy structures into a file and still have it
human readable (through creative use of white-space for example), I don't
think it would be possible to do so and still have it human writable. If
the human doesn't understand the significance of the white space, then it
would not be possible for them to edit the file without corrupting it.
So it is just a matter of what modules (if any) to use to read and write
the file. I'd turn that around. Instead of looking at every possible
module and asking if the format it uses is acceptable to the humans, ask
format do the human readers/writers want to use.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 26 Apr 2007 23:14:47 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Readable/writable database in Perl
Message-Id: <x7y7ke4ifs.fsf@mail.sysarch.com>
>>>>> "E" == Eric <ecarlson@vmware.com> writes:
E> Sherm Pendley wrote:
>> Eric <ecarlson@vmware.com> writes:
>>
>> Upside-down - please don't do that! English reads from top to bottom.
>>
>> > Brian McCauley wrote:
>> >>
>> >> Well, if you want to use a human readable database you'd do better to
>> >> use a database module that uses flat files, like say DBD::CSV or
>> >> DBD::AnyData.
>> >
>> > Thanks for this direction, Brian. I will certainly look into this.
>>
>> Replies belong below the quoted text, like this.
>>
>> sherm--
>>
E> Unless you're replying to an email, in which case the reply text goes
E> at the top before the replied to text. :)
no, that is still top posting. too bad redmond ruined the email world by
their breaking of a smart and long standing netiquette rule.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Thu, 26 Apr 2007 23:45:33 -0700
From: Joe Smith <joe@inwap.com>
Subject: Re: Readable/writable database in Perl
Message-Id: <UIidnUz6hqGSAazbnZ2dnUVZ_q-vnZ2d@comcast.com>
Eric wrote:
> Currently, our code is utilizing a database that is neither humanly
> readable or writable. My task is to modify the existing code so that
> the database is both.
If it is to be readable and writable by humans but read-only to machines,
then you could do what sendmail does.
The file /etc/mail/aliases has a very simple format - it is designed to
be read and written by the system administrator. But performing a
sequential search on the plain-text file is very inefficient. So the
sendmail package comes with a 'newaliases' command. That command reads
/etc/mail/aliases and creates /etc/mail/aliases.db, which is a database
optimized for doing fast lookups. The master file is the plain-text
one and the database is derived from it.
An alternative is to have the database be the definitive version.
Whenever the data needs to be edited by a human, the entire database
could be converted to a temporary plain-text file. Then when the
human is finished editing, the database can be re-created from the
modified plain-text file. (You'd have to have some sort of locking
mechanism to ensure that no machine-generated updates are allowed
while the human is editing.)
Back in the days of Perl 4, I had a program that kept track of files
and their checksums so that I could avoid duplicates and avoid doing
unnecessary I/O to magneto-optical disks. During it development, I
made sure it had an 'export' command to dump the data into a flat file,
and an 'import' command to rebuild the dbm file from it. The flat file
would exist just long enough to do a global search-and-replace, and would
be deleted as soon as the database of binary data was rebuilt.
-Joe
------------------------------
Date: Thu, 26 Apr 2007 23:49:46 -0700
From: Joe Smith <joe@inwap.com>
Subject: Re: Readable/writable database in Perl
Message-Id: <e66dnRAwzrWRAKzbnZ2dnUVZ_gKdnZ2d@comcast.com>
Eric wrote:
> Sherm Pendley wrote:
>> Replies belong below the quoted text, like this.
>
> Unless you're replying to an email, in which case the reply text goes
> at the top before the replied to text. :)
Only pointy-haired bosses forwarding messages with "Here, you take are of this"
are allowed to do that.
------------------------------
Date: 26 Apr 2007 23:40:16 -0700
From: Brian McCauley <nobull67@gmail.com>
Subject: Re: SQL statement in Perl doesn't work
Message-Id: <1177656015.900725.183820@r30g2000prh.googlegroups.com>
On Apr 26, 9:05 pm, Glenn Jackman <gle...@ncf.ca> wrote:
> At 2007-04-26 03:13PM, "Huub" wrote:
>
> > Alright. There are indeed some more lines in between:
>
> > $betaald2006 = "select betaald2006 from hvw where lidnr = $record and
> > naam != ' ' and kenmerk2006 is null";
> > $sth = $dbh->prepare($betaald2006);
> > $sth->execute or die "SQL Error: $DBI::errstr\n";
> > @betaald2006 = $sth->fetchrow_array;
> > $betaald2006 = @betaald2006;
> > $betaald2006 = $betaald2006[0];
> > $vergelijk = "N";
> > if ($betaald2006 eq $vergelijk)
> > {
>
> So, clearly, the first column of the first row returned by your query is
> null (defined($betaald2006[0]) is false).
Or the query returned no rows.
------------------------------
Date: 26 Apr 2007 23:47:01 -0700
From: Brian McCauley <nobull67@gmail.com>
Subject: Re: SQL statement in Perl doesn't work
Message-Id: <1177656418.794323.297780@n15g2000prd.googlegroups.com>
On Apr 26, 8:44 pm, "J. Gleixner" <glex_no-s...@qwest-spam-no.invalid>
wrote:
> use Data::Dumper;
> print Dumper( @betaald2006 );
It's better to dump @betaald2006 as a single variable
print Dumper( \ @betaald2006 );
> Also, if you're only after the first row, use 'limit 1' in your SQL.
I'm not sure that the lack of portability of using a non-standard SQL
extension is justified.
------------------------------
Date: 26 Apr 2007 16:18:05 -0700
From: Klaus <klaus03@gmail.com>
Subject: Re: STDOUT redirection
Message-Id: <1177629485.284197.200140@o40g2000prh.googlegroups.com>
On Apr 26, 8:47 pm, para...@gmail.com wrote:
> On Apr 26, 1:29 am, Klaus <klau...@gmail.com> wrote:
> > I am guessing that your function call has external commands (for
> > example system(), `...`, qx(), etc...).
> Thanks for the tip - yes my code does use external perl modules to
> return values
Please copy and paste a section from your perl program where you
actually call the external perl modules (if possible no more than 10
lines).
--
Klaus
------------------------------
Date: Thu, 26 Apr 2007 21:49:55 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: STDOUT redirection
Message-Id: <slrnf32p6j.el3.tadmc@tadmc30.august.net>
paraagv@gmail.com <paraagv@gmail.com> wrote:
> On Apr 26, 1:29 am, Klaus <klau...@gmail.com> wrote:
>> I am guessing that your function call has external commands (for
>> example system(), `...`, qx(), etc...).
>> --
>> Klaus
It is bad netiquette to quote signatures.
> Thanks for the tip - yes my code does use external perl modules to
> return values
A "command" is not the same thing as a "module".
He did not ask if you use external modules, he asked if you
used external (command line) commands.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 27 Apr 2007 10:03:51 +0300
From: Alex <check.sig@for.email.invalid>
Subject: Re: UTF8 European characters in MySQL
Message-Id: <AfhYh.44643$bu6.43143@reader1.news.saunalahti.fi>
John wrote:
> I have created a table with
>
> DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci
>
> However, the European accented characters appear incorrectly.
A little more information would be helpful. What do they look like? How
do you view them? ( in mysql's cli, in html, etc.?) What are your locale
settings? Do you 'use utf8' in you perl script? What system are you
running your script on?
> What is the standard accepted way to read/write European accented characters
> in Perl using MySql database?
Utf-8 is the new one. ISO-8859-1 (or ISO-8859-15) is the old one and
still works, but is restricted to western characters.
--
Alex
e-mail: Domain is iki dot fi. Local-part is alext.
local-part at domain
------------------------------
Date: 27 Apr 2007 00:08:34 -0700
From: AK444 <Arao44@gmail.com>
Subject: video lectures on C, C++, Java, Python and other programming and Computer science.
Message-Id: <1177657714.433306.164040@o40g2000prh.googlegroups.com>
Hi Friends,
Check here http://freevideolectures.com/computerscience.html for
video lectures on Programming languages like C, C++, Java, COBOL
etc.., OS, Algorithms, Data Structures, RDBMS,
Web designing, etc..........
It also has amazing collection of video lectures and animations on all
Engineering and Medical Sciences. I am sure you will be surprised to
see such great collection.
Do you like it???
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 386
**************************************
