php-general Digest 29 Oct 2008 21:11:48 -0000 Issue 5762
Topics (messages 282558 through 282585):
Re: Waste of storage space?
282558 by: Frank Arensmeier
282560 by: Frank Arensmeier
282561 by: Frank Arensmeier
282562 by: Maciek Sokolewicz
282573 by: Bastien Koert
282577 by: Aschwin Wesselius
282579 by: Bastien Koert
282580 by: Aschwin Wesselius
Re: FImage $aSubDir
282559 by: Ashley Sheridan
282563 by: Maciek Sokolewicz
Newbie: can I store flash file into Mysql DB
282564 by: vuthecuong
282565 by: Stut
282566 by: vuthecuong
282567 by: Stut
282568 by: vuthecuong
282572 by: Bastien Koert
Mailing lists
282569 by: Richard Heyes
282570 by: Dotan Cohen
282571 by: Bjoern Bartels
282575 by: Michael Kubler
282576 by: Wolf
282582 by: Daniel P. Brown
Re: Regex validation
282574 by: Bastien Koert
282578 by: ceo.l-i-e.com
282581 by: Yeti
Re: create/write to psd file
282583 by: David Lidstone
282584 by: Ashley Sheridan
General Mysql Connect
282585 by: Waynn Lue
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
28 okt 2008 kl. 23.56 skrev Chris:
1) Store the "delta" (=the actual change) of a text change. This
could be done by utilizing the Pear package TextDiff. My idea was
to compare the old with the new text with help of the TextDiff
class. I would then grab the array containing the changes from
TextDiff, serialize it and store this data into the db. The problem
is that this is every thing else but efficient when it comes to
smaller text (the serialized array holding the changes was actually
larger than the two texts combined).
What happens when you want to restore a particular version? You have
to go through each edition and apply patches. Could get very messy.
Not only that. What would happen if they update TextDiff and all
stored serialized arrays got obsolete? The system is aimed to store
documents for several years to come. Besides that, doing some advanced
search in the "history/revision" table would be very difficult.
I'd say you're on the right track in just storing each version.
2) Do some kind of compression on the text to be stored. However,
it seems that the build-in compression functions from PHP5 are more
efficient when it comes to large texts.
All compression techniques (in or out of php) will work better on
more text.
I noticed that too.
//frank
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
29 okt 2008 kl. 00.00 skrev Maciek Sokolewicz:
Frank Arensmeier wrote:
Hi all.
In short, I am working on a system that allows me to keep track of
changes to a large amount of short texts (a couple of thousand text
snippets, two or three sentences per text). All text is stored in a
database. As soon as a user changes some text (insert, delete,
update), this action is recorded. Look at an article on e.g.
Wikipedia and click "History". This is more or less what I am
trying to accomplish.
Right now, my "history" class that takes care of all changes, is
working pretty much as I want. The thing is that both the original
text and the altered text is stored in the database every time the
text is changed. My concern is that this will eventually evolve
into a serious problem regarding amount of storage and performance.
So, I am looking for a more efficient way to store all changes.
Ideas I have come up with so far are:
1) Store the "delta" (=the actual change) of a text change. This
could be done by utilizing the Pear package TextDiff. My idea was
to compare the old with the new text with help of the TextDiff
class. I would then grab the array containing the changes from
TextDiff, serialize it and store this data into the db. The problem
is that this is every thing else but efficient when it comes to
smaller text (the serialized array holding the changes was actually
larger than the two texts combined).
2) Do some kind of compression on the text to be stored. However,
it seems that the build-in compression functions from PHP5 are more
efficient when it comes to large texts.
Any other ideas?
thank you.
//frank
ps. I notice that Mediawiki also stores complete articles in the db
(every time an article is updated, the hole article is stored in
the database). ds.
Hi Frank,
why don't you simply make use of systems specifically designed for
such things. eg. CVS or SVN (subversion.tigris.org). You could
pretty easily tie it in with your application. It's quite compact,
and pretty fast too.
- Tul
Hi Tul.
I think would be an idea worth investigating a little bit more. But
what about performance? I am really not that familiar with version
control systems like CVS etc. Let's say there are 30 different text
snippets with 10 recorded changes each. And I want to see what changes
users have made to those snippets. That would be 300 calls to the
(filesystem based) CVS system. Would that be overheat? Besides that,
in the database I am able to store more information about those
recorded changes. E.g. the user ID and the time is currently stored as
well. Can this be done with CVS as well?
/frank
--- End Message ---
--- Begin Message ---
29 okt 2008 kl. 01.08 skrev Bastien Koert:
On Tue, Oct 28, 2008 at 4:24 PM, Frank Arensmeier
<[EMAIL PROTECTED]> wrote:
Hi all.
In short, I am working on a system that allows me to keep track of
changes to a large amount of short texts (a couple of thousand text
snippets, two or three sentences per text). All text is stored in a
database. As soon as a user changes some text (insert, delete,
update), this action is recorded. Look at an article on e.g.
Wikipedia and click "History". This is more or less what I am trying
to accomplish.
Right now, my "history" class that takes care of all changes, is
working pretty much as I want. The thing is that both the original
text and the altered text is stored in the database every time the
text is changed. My concern is that this will eventually evolve into
a serious problem regarding amount of storage and performance. So, I
am looking for a more efficient way to store all changes.
Ideas I have come up with so far are:
1) Store the "delta" (=the actual change) of a text change. This
could be done by utilizing the Pear package TextDiff. My idea was to
compare the old with the new text with help of the TextDiff class. I
would then grab the array containing the changes from TextDiff,
serialize it and store this data into the db. The problem is that
this is every thing else but efficient when it comes to smaller text
(the serialized array holding the changes was actually larger than
the two texts combined).
2) Do some kind of compression on the text to be stored. However, it
seems that the build-in compression functions from PHP5 are more
efficient when it comes to large texts.
Any other ideas?
thank you.
//frank
ps. I notice that Mediawiki also stores complete articles in the db
(every time an article is updated, the hole article is stored in the
database). ds.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Save just the new version each time
table like
record_id //PK
relates_to //FK
item_text
author_id
timestamp
much easier to work with
Yes, maybe it's just as simple as that. Thanks.
//frank
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
Frank Arensmeier wrote:
29 okt 2008 kl. 00.00 skrev Maciek Sokolewicz:
Frank Arensmeier wrote:
Hi all.
In short, I am working on a system that allows me to keep track of
changes to a large amount of short texts (a couple of thousand text
snippets, two or three sentences per text). All text is stored in a
database. As soon as a user changes some text (insert, delete,
update), this action is recorded. Look at an article on e.g.
Wikipedia and click "History". This is more or less what I am trying
to accomplish.
Right now, my "history" class that takes care of all changes, is
working pretty much as I want. The thing is that both the original
text and the altered text is stored in the database every time the
text is changed. My concern is that this will eventually evolve into
a serious problem regarding amount of storage and performance. So, I
am looking for a more efficient way to store all changes.
Ideas I have come up with so far are:
1) Store the "delta" (=the actual change) of a text change. This
could be done by utilizing the Pear package TextDiff. My idea was to
compare the old with the new text with help of the TextDiff class. I
would then grab the array containing the changes from TextDiff,
serialize it and store this data into the db. The problem is that
this is every thing else but efficient when it comes to smaller text
(the serialized array holding the changes was actually larger than
the two texts combined).
2) Do some kind of compression on the text to be stored. However, it
seems that the build-in compression functions from PHP5 are more
efficient when it comes to large texts.
Any other ideas?
thank you.
//frank
ps. I notice that Mediawiki also stores complete articles in the db
(every time an article is updated, the hole article is stored in the
database). ds.
Hi Frank,
why don't you simply make use of systems specifically designed for
such things. eg. CVS or SVN (subversion.tigris.org). You could pretty
easily tie it in with your application. It's quite compact, and
pretty fast too.
- Tul
Hi Tul.
I think would be an idea worth investigating a little bit more. But
what about performance? I am really not that familiar with version
control systems like CVS etc. Let's say there are 30 different text
snippets with 10 recorded changes each. And I want to see what changes
users have made to those snippets. That would be 300 calls to the
(filesystem based) CVS system.
30 calls actually, not 300
Would that be overheat? Besides that, in the database I am able to
store more information about those recorded changes. E.g. the user ID
and the time is currently stored as well. Can this be done with CVS as
well?
you can store a userid with these pretty easily (easier with svn than
with cvs). And the exact date/time is stored automatically aswell.
/frank
--- End Message ---
--- Begin Message ---
>
>
>
> Thank you for your respons.
>
> I have thought of such a sorting mechanism too. But on the other hand, the
> biggest drawback would be that even minor changes that might be really
> important could get lost. And my goal is to really keep track on everything
> my users do. And, in the long run, the problem with the database that
> eventually could/will grow very large in size, is not solved.
>
> //frank
>
> ..please keep responses on list.
>
>
>
I think you need to look at a lifetime value of the text element. Do they
age at all? suggesting that you could archive them off if they are not being
used after a certain period of time. You can also isolate the text portion
of this to one table and then consider things like partitioning the table
for speed.
We do something similar here and in one table we have +220000 records taking
up 112Mb of space. But we can archive off eveything that is 7 years and
older
And lets face it, on the issue of size, disk space is cheap.
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
Bastien Koert wrote:
Thank you for your respons.
I have thought of such a sorting mechanism too. But on the other hand, the
biggest drawback would be that even minor changes that might be really
important could get lost. And my goal is to really keep track on everything
my users do. And, in the long run, the problem with the database that
eventually could/will grow very large in size, is not solved.
//frank
..please keep responses on list.
I think you need to look at a lifetime value of the text element. Do they
age at all? suggesting that you could archive them off if they are not being
used after a certain period of time. You can also isolate the text portion
of this to one table and then consider things like partitioning the table
for speed.
We do something similar here and in one table we have +220000 records taking
up 112Mb of space. But we can archive off eveything that is 7 years and
older
And lets face it, on the issue of size, disk space is cheap.
Hi,
Ok, disk space is cheap, but you can't avoid the access/seek time
penalty on this.
- Unomi -
--- End Message ---
--- Begin Message ---
>
> Hi,
>
> Ok, disk space is cheap, but you can't avoid the access/seek time penalty
> on this.
>
> - Unomi -
>
Properly indexed, its not that bad...after all its what Dbs do best
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
Bastien Koert wrote:
Hi,
Ok, disk space is cheap, but you can't avoid the access/seek time penalty
on this.
- Unomi -
Properly indexed, its not that bad...after all its what Dbs do best
I only mention this, that while disk space seems a unlimited resource
these days the fact that a DB gets it's bottleneck here is paramount.
I suggest to look up articles about this on www.mysqlperformanceblog.com
to find some hints and tips to avoid most of the issues with huge disk
space and record access.
And BTW, 'properly indexed' is mostly easier said than done.
- Unomi -
--- End Message ---
--- Begin Message ---
On Tue, 2008-10-28 at 23:52 -0400, John Taylor-Johnston wrote:
> Could it be this easy?
>
> $chopped= strlen($aFn) - 4;
> $filename = $chopped.".txt";
>
> print"<br><font face='Arial, Helvetica, sans-serif' size=2
> color='#999999'>";
> include($filename);
> print"</font>";
>
> John Taylor-Johnston wrote:
> > I have http://www.flash-here.com/downloads/fhimage.html installed. I
> > like it just the way it is.
> > But instead of displaying (see function below).
> > Instead of displaying the file name under the photo, weak excuse for a
> > caption,
> > I would like to open and nl2br the contents of a like named text file.
> >
> > $chopped= strlen($aFn) - 4;
> > $openthis = $chopped.".txt";
> >
> > How do I proceed?
> > John
> >
> > ---original code----
> > echo "<br><center>";
> > if($aSubDir == "") {
> > $l = strlen($aFn) - 4;
> > echo substr($aFn, 0, $l);
> > } else {
> > echo $aSubDir."[dir]";
> > }
> > echo "</center>";
>
>
Yeah, but don't use the font tag.
Ash
www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
On Tue, 2008-10-28 at 23:52 -0400, John Taylor-Johnston wrote:
Could it be this easy?
$chopped= strlen($aFn) - 4;
$filename = $chopped.".txt";
print"<br><font face='Arial, Helvetica, sans-serif' size=2
color='#999999'>";
include($filename);
print"</font>";
John Taylor-Johnston wrote:
I have http://www.flash-here.com/downloads/fhimage.html installed. I
like it just the way it is.
But instead of displaying (see function below).
Instead of displaying the file name under the photo, weak excuse for a
caption,
I would like to open and nl2br the contents of a like named text file.
$chopped= strlen($aFn) - 4;
$openthis = $chopped.".txt";
How do I proceed?
John
---original code----
echo "<br><center>";
if($aSubDir == "") {
$l = strlen($aFn) - 4;
echo substr($aFn, 0, $l);
} else {
echo $aSubDir."[dir]";
}
echo "</center>";
Yeah, but don't use the font tag.
Ash
www.ashleysheridan.co.uk
and no because you can't apply nl2br easily on the thing you included
there unless you use output buffering. You wanted to "open" a file and
nl2br it. How? You could use the fopen function (surprise, surprise) and
the nl2br function (wow) later on. Of course these days it's easier to
call file_get_contents($filename) and apply nl2br on its return value.
- Tul
--- End Message ---
--- Begin Message ---
technically can I store flash file into Mysql DB using PHP?
what point should I pay attention for that?
Thank you
--
View this message in context:
http://www.nabble.com/Newbie%3A-can-I-store-flash-file-into-Mysql-DB-tp20224150p20224150.html
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
On 29 Oct 2008, at 10:20, vuthecuong wrote:
technically can I store flash file into Mysql DB using PHP?
Yes.
what point should I pay attention for that?
The blob field type.
But I would recommend against it. Why not store the files on disk and
only store the filenames in the DB?
-Stut
--
http://stut.net/
--- End Message ---
--- Begin Message ---
Stut wrote:
>
> On 29 Oct 2008, at 10:20, vuthecuong wrote:
>> technically can I store flash file into Mysql DB using PHP?
>
> Yes.
>
>> what point should I pay attention for that?
>
> The blob field type.
>
> But I would recommend against it. Why not store the files on disk and
> only store the filenames in the DB?
>
> -Stut
>
> --
> http://stut.net/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
Thanks for fast reply. Could you tell me the reason against it?
regards,
--
View this message in context:
http://www.nabble.com/Newbie%3A-can-I-store-flash-file-into-Mysql-DB-tp20224150p20224340.html
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
On 29 Oct 2008, at 10:32, vuthecuong wrote:
Stut wrote:
On 29 Oct 2008, at 10:20, vuthecuong wrote:
technically can I store flash file into Mysql DB using PHP?
Yes.
what point should I pay attention for that?
The blob field type.
But I would recommend against it. Why not store the files on disk and
only store the filenames in the DB?
Thanks for fast reply. Could you tell me the reason against it?
In my experience it's a lot harder to manage than files. DB backups
and restores start taking a long time - not good when disaster strikes
and you need to get back up and running quickly. Scripts that serve
blobs can take up a lot of memory since they need to load the entire
blob before outputting it to the browser whereas files can be streamed.
Google for something like store files in mysql and you'll find a lot
of opinion on the advantages and disadvantages. If the files are small
enough and there aren't many then it can work well, but personally I'd
never do it again after some nasty experiences a few years back.
-Stut
--
http://stut.net/
--- End Message ---
--- Begin Message ---
Stut wrote:
>
> On 29 Oct 2008, at 10:32, vuthecuong wrote:
>>
>> Stut wrote:
>>>
>>> On 29 Oct 2008, at 10:20, vuthecuong wrote:
>>>> technically can I store flash file into Mysql DB using PHP?
>>>
>>> Yes.
>>>
>>>> what point should I pay attention for that?
>>>
>>> The blob field type.
>>>
>>> But I would recommend against it. Why not store the files on disk and
>>> only store the filenames in the DB?
>>>
>> Thanks for fast reply. Could you tell me the reason against it?
>
> In my experience it's a lot harder to manage than files. DB backups
> and restores start taking a long time - not good when disaster strikes
> and you need to get back up and running quickly. Scripts that serve
> blobs can take up a lot of memory since they need to load the entire
> blob before outputting it to the browser whereas files can be streamed.
>
> Google for something like store files in mysql and you'll find a lot
> of opinion on the advantages and disadvantages. If the files are small
> enough and there aren't many then it can work well, but personally I'd
> never do it again after some nasty experiences a few years back.
>
> -Stut
>
> --
> http://stut.net/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
THanks Stut, I learned from you a lot. I'll take that into account.
regards
--
View this message in context:
http://www.nabble.com/Newbie%3A-can-I-store-flash-file-into-Mysql-DB-tp20224150p20224881.html
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
On Wed, Oct 29, 2008 at 6:20 AM, vuthecuong <[EMAIL PROTECTED]> wrote:
>
> technically can I store flash file into Mysql DB using PHP?
> what point should I pay attention for that?
> Thank you
> --
> View this message in context:
> http://www.nabble.com/Newbie%3A-can-I-store-flash-file-into-Mysql-DB-tp20224150p20224150.html
> Sent from the PHP - General mailing list archive at Nabble.com.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
We used to do that here, and there was significant performance impact after
the database got to be about 12Gb, with minor impact showing after only a
few Gb. I ended up having to write a script that stripped all the data from
the Db into the file system.
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
Hi,
Anyone know of a good (as opposed to a bad) mailing list manager,
other than freelists.org (which I can't seem to get working).
Thanks.
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated October 25th)
--- End Message ---
--- Begin Message ---
2008/10/29 Richard Heyes <[EMAIL PROTECTED]>:
> Hi,
>
> Anyone know of a good (as opposed to a bad) mailing list manager,
> other than freelists.org (which I can't seem to get working).
>
> Thanks.
>
Gmail!
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
ä-ö-ü-ß-Ä-Ö-Ü
--- End Message ---
--- Begin Message ---
Dotan Cohen wrote ..
> 2008/10/29 Richard Heyes <[EMAIL PROTECTED]>:
> > Hi,
> >
> > Anyone know of a good (as opposed to a bad) mailing list manager,
> > other than freelists.org (which I can't seem to get working).
> >
> > Thanks.
> >
>
> Gmail!
?!? that's ajoke, right?....
i pledge loyalty for gnus mailman
http://www.gnu.org/software/mailman/index.html
cheers
bb
--- End Message ---
--- Begin Message ---
I agree.
Mailman has everything you need from a mailing list and is the defacto
standard.
Besides, with it you only need to press 'reply' not 'Reply all' when
trying to send to the list... unlike this one.
Usually you would setup it up on a subdomain (e.g _lists.__domain.com_)
and can then have multiple lists on that domain, such as
[EMAIL PROTECTED], [EMAIL PROTECTED] etc..
Michael Kubler
*G*rey *P*hoenix *P*roductions <http://www.greyphoenix.biz>
Bjoern Bartels wrote:
Dotan Cohen wrote ..
2008/10/29 Richard Heyes <[EMAIL PROTECTED]>:
Hi,
Anyone know of a good (as opposed to a bad) mailing list manager,
other than freelists.org (which I can't seem to get working).
Thanks.
?!? that's ajoke, right?....
i pledge loyalty for gnus mailman
http://www.gnu.org/software/mailman/index.html
cheers
bb
--- End Message ---
--- Begin Message ---
---- Richard Heyes <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Anyone know of a good (as opposed to a bad) mailing list manager,
> other than freelists.org (which I can't seem to get working).
>
> Thanks.
What's wrong with Mailman?
Wolf
--- End Message ---
--- Begin Message ---
On Wed, Oct 29, 2008 at 9:26 AM, Wolf <[EMAIL PROTECTED]> wrote:
>
> What's wrong with Mailman?
That's what I'd recommend, too. It's not PHP, but it's tried and
true, tested over years and years, and probably in the millions or
tens of millions of messages handled.
--
</Daniel P. Brown>
http://www.parasane.net/
[EMAIL PROTECTED] || [EMAIL PROTECTED]
Ask me about our current hosting/dedicated server deals!
--- End Message ---
--- Begin Message ---
On Tue, Oct 28, 2008 at 8:57 PM, VamVan <[EMAIL PROTECTED]> wrote:
> SSO process:
>
> $_POST the Email Address and password
>
> Get Authenticated, Get the COOKIE ( Through Oracle IDM suite SOAP call)
>
> Decrypt the COOKIE ( Through Oracle Enterprise business suite SOAP call)
>
> and get the profile Info
>
> Thats what happens now.
>
> But there is a glitch in the decryption algorithm we currently have. And
> when we decrypt + or some thing else comes with funny characters and does
> not authenticate.
>
> So I need to restrict them for now. When the algorithm gets corrected then
> I
> will use standard RFC.
>
>
>
>
>
Are they not base64 encoded? I have had issues in decrypting elements that
were not base64 encoded as some characters would end up mimicing EOL or
otherwise dropping data
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
When it comes to email validation, I would recommend using the IMAP function
which will be both fast and correct:
http://us.php.net/manual/en/function.imap-rfc822-parse-adrlist.php
Otherwise, it's guaranteed that you are having at least some false positives,
and probably some false negatives.
--- End Message ---
--- Begin Message ---
On Wed, Oct 29, 2008 at 5:36 AM, <[EMAIL PROTECTED]> wrote:
>
> When it comes to email validation, I would recommend using the IMAP function
> which will be both fast and correct:
>
> http://us.php.net/manual/en/function.imap-rfc822-parse-adrlist.php
>
> Otherwise, it's guaranteed that you are having at least some false positives,
> and probably some false negatives.
Didn't know about those IMAP functions. And they even work in PHP4.
Thanks for telling.
--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
On Mon, 2008-10-27 at 07:55 +0100, Martin Zvarík wrote:
What I know is that you can control GIMP over the command line = you can
use PHP to do this.
Though I guess GIMP doesn't support PSD files, I had to express myself
anyways.
vuthecuong napsal(a):
Hi all
Is there a way to create/read/write to psd file? (photoshop format)
I would like to hear opinion form you:
Do you recommend gd2 or imageMagick to perform this task? and why
thanks in advanced
The Gimp does support PSD files, but it has real trouble with the layer
effects that CS introduced. Also, the Gimp cannot natively handle CMYK
images.
Ash
www.ashleysheridan.co.uk
And off the top of my head, I don't think it supports 24bit images
either, which can be another killer if you want to handle images from CS.
--- End Message ---
--- Begin Message ---
On Wed, 2008-10-29 at 15:22 +0000, David Lidstone wrote:
> Ashley Sheridan wrote:
> > On Mon, 2008-10-27 at 07:55 +0100, Martin Zvarík wrote:
> >> What I know is that you can control GIMP over the command line = you can
> >> use PHP to do this.
> >>
> >> Though I guess GIMP doesn't support PSD files, I had to express myself
> >> anyways.
> >>
> >>
> >> vuthecuong napsal(a):
> >>> Hi all
> >>> Is there a way to create/read/write to psd file? (photoshop format)
> >>>
> >>> I would like to hear opinion form you:
> >>> Do you recommend gd2 or imageMagick to perform this task? and why
> >>> thanks in advanced
> > The Gimp does support PSD files, but it has real trouble with the layer
> > effects that CS introduced. Also, the Gimp cannot natively handle CMYK
> > images.
> >
> >
> > Ash
> > www.ashleysheridan.co.uk
> >
>
> And off the top of my head, I don't think it supports 24bit images
> either, which can be another killer if you want to handle images from CS.
>
I thought 24-bit meant CMYK; 8 bits each for Cyan, Magenta, Yellow and
Black. I know the Gimp can handle PNG graphics which are 24-bit though;
Red, Green, Blue and an Alpha channel.
Ash
www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
I sent an email to the mysql list, but it reminded me of a question I had
for people structuring their PHP code. What's the general way that people
structure their connections? Right now, I spawn off two mysql_connect calls
at the top of the file that includes my database calls, using "true" for the
fourth parameters, so as to create two new connections. Then I use those
two connections for two different databases I have to query from.
Is it better just to use mysql_select_db within the query function every
time for the same connection? Should I use mysql_connect every time without
using "true", so as to re-use connections. Should I be using pconnect
instead?
I spent some time looking for answers to these questions, but am getting
conflicting answers. Some people think relying on the re-use of these
functions is good, some think that explicit management is better. In
general, how have people on the list found them? For example, is having
constant mysql_select_db calls a problem?
Thanks,
Waynn
On Wed, Oct 29, 2008 at 2:47 AM, Waynn Lue <[EMAIL PROTECTED]> wrote:
> We've started seeing mysql errors in the logs, and when i look at the
> output of mysql_error() (in php), i get "lost connection to mysql server
> during query". Here's an example stack trace:
>
> 'Can't connect to <name> database [Lost connection to MySQL server during
> query]'
>
> Similarly, we're seeing stack traces here as well:
>
> 'Can't connect to <name> database []'
>
> I usually only see this mesasge when I don't use a connection for awhile
> and it timeouts, but in this case, the connection is only opened for the
> duration of a script, which can't be running for more than a second. The
> mysql error logs don't show anything, and wait_timeout is set to 28800.
>
> At first, I thought it was because I was calling mysql_select_db too much,
> so I ended up using two mysql connections per page load, but that didn't
> seem to change anything. How can we prevent this error from happening, what
> else can I do to diagnose this further? Google brings up some more
> discussions about it, but nothing seems related to this, like packetsize.
> This is happening when we select two ids from a database. And SHOW
> PROCESSLIST shows that the number of connections aren't even coming close to
> max connections.
>
> Thanks for any advice,
> Waynn
>
--- End Message ---
