princepawn wrote:

how would you hide the user and pass outside of an EZDBI script?

Put the username and password in another file that only the script owner has permissions to. You can just open and read it or use something like App::Config if your configuration information gets to be complicated. Using Storable for a quick and dirty solution is another option.

I agree that the namespace is a bit odd.

Cheers,
Ovid

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

how would you hide the user and pass outside of an EZDBI script?

I would rather get back hashrefs instead of arrays.

And are those arrays all in memory at once? Or are they tied to something that does incremental fetches?

And how about a convenience update_unless_insert which inserts a row if it can, otherwise, does an update on it....

--
Mark Dominus
Perl Paraphernalia

It's not always better to squander space: doing so may result in the program not working at all. Squandering time just makes it run slowly. But that's more of a philosophical point.

WRT the update_unless_insrt: there isn't such an option: PrincePawn's referring to the sort of situation where you've got enough information to create a record from scratch, or replace an existing one.

Thus (under Oracle) you get code similar to:

BEGIN
  INSERT INTO mytab (id, ...) VALUES (id_value, ...);
EXCEPTION
WHEN DUP_VAL THEN
  UPDATE mytab
  SET .. = ...
  WHERE id=id_value;
END;
[download]

. id would presumably be limited to the primary key, rather than any unique key. Personally, I think I'd prefer to see it as inserting if the update fails (which avoids the problem of duplicating a different column).

tommyw says:

It's not always better to squander space

Well, I didn't say it was always better, did I? I just said it was better.

WRT the update_unless_insrt: there isn't such an option

I think I may have been thinking of MySQL's REPLACE syntax. It might be well worth emulating REPLACE with if (UPDATE fails) { try INSERT } if it could be done portably. But I do not think it can be. One problem is that the UPDATE might fail for some other reason, and understanding whether it is safe to proceed with the INSERT seems difficult.

You also suggest that I ignore the issue of multiple unique keys, and concentrate on just the primary key. But this doesn't make the problem any easier, and it would make the behavior a lot more confusing for the user. I think doing that would do the wrong thing a lot of the time, and then people would be upset.

Still, I should look into making this easier than it presently is. Right now, you would have to write something like

    eval { UPDATE ... } or INSERT ...;
[download]

Which seems rather bizarre.

--
Mark Dominus
Perl Paraphernalia