[Perl] FileHandles en Windows....

[=?ISO-8859-1?Q?Max_de_Mendiz=E1bal?=]

La verdad no son nada complicados de entender. Cualquier SQL es much=EDsi=
mo=20
m=E1s complicado. =BFYa leyeron la documentaci=F3n de todos los dbms? En=20
http://www.sleepycat.com viene muy bien. Puedes hacer hashes de varios=20
terabytes, entre otras monadas. Jala con C, Perl o lo que quieras. Si lo=20
aprendes a usar bien a los mejor no vuelves a necesitar ninguna base de=20
datos relacional.

Saludos
Max

On Tue, 2 Apr 2002, Rodrigo Gallardo wrote:

> Alejandro G. Bedoya writes:
>  > >Antes de continuar, te vuelvo a sugerir echarle un ojo a la funci=F3=
n tie de
>  > >Perl (perldoc -f tie, o si est=E1s en Windows, debe estar dentro de=
 la
>  > >p=E1gina de ayuda de perlfunc). Esto te permite hacer algo as=ED: (=
tomado de
>  > >esa p=E1gina)
>  >=20
>  >     Si, ya hace mucho habia visto esa posibilidad, y la verdad no le
>  > entendi. Y por lo general si es complicado de explicar/entender, ent=
onces es
>  > complicado de usar. Lo volvi a ver y sigo si entenderle("man perltie=
" est=E1
>  > mas completo), muy seguramente porque se maneja como objeto y a mi
>  > penosamente no se me da eso...
>=20
> Ahi si no le atinaste. Precisamente son complicados de entender por
> que son muy faciles de usar. La documentacion que estas leyendo es
> para implementar uno mismo el acceso. Pero hay modulos que ya lo
> hacen, por lo menos para casos como el que estamos tratando. Nadamas
> le dices:
>=20
> use AnyDBM_File;
> tie %tu_hash, 'AnyDBM_File', 'un_archivo';
>=20
> Y ya, a partir de ese momento, todo acceso a %tu_hash, no se da en
> memoria, sino en el disco.
>=20
>=20
>  >     Adem=E1s, por ahi mencionaron que se manejan como binarios, pues=
 no me
>  > sirve entonces. Por lo que sale mas barato comprarle m=E1s memoria a=
 la compu
>  > que usar     TIEs para mi caso. Tambien quien sabe como le hagas par=
a
>  > relacionar una tabla con otra... como yo lo hago es f=E1cil gracias =
a perl:
>  >=20
>  > my %Usuarios=3D&GETNDBFILE1("usuarios.ndb");
>  > my %Ordenes=3D&GETNDBFILE1("ordenes.ndb");
>  > my $IDord=3D50;
>  > print "La orden $IDord la hizo
>  > $Usuarios{$Ordenes{$IDord}{'IDUSUARIO'}}{'NOMBRE'}.";
>=20
> Le haces igual.
>=20
>=20
>  >=20
>  > Sin embargo, mi objetivo es hacer una nueva funcion con algo parecid=
o a:
>  >=20
>  > my %Usuarios=3D&GETNDBFILE2("select * from usuarios where estado=3D1=
 orderby
>  > nombre");
>  >=20
>  >     Aqui seguirias usando los archivos NDB, pero los accesas tipo SQ=
L,
>  > ahorrandote memoria ya que usarias el where, y luego ordenados con e=
l
>  > orderby, todo lo que no hace mi funci=F3n actual. Aunque creo que es=
o ya lo
>  > hace el DBI con archivos planos. El problema aqui es hacer el parser=
 SQL.
>  > Eso me mantendr=E1 entretenido un buen rato. =3D)
>=20
> =BFY para que trabajas si alguien ya lo hizo? Seguramente alguno de
> DBD::RAM, DBD::SQLite o DBD::CSV hace lo que necesitas. Y si no, estan
> cerca, as=ED que mejor contribuye a ellos, ahorrate trabajo, y coopera
> con la comunidad. O si en tu proyecto no te permiten cooperar, por lo
> menos ahorrate chamba.
>=20
>  >=20
>  > >Yo creo que se debe a la manera en que Unix y Windows manejan la
>  > >memoria... Probablemente en Windows Perl tenga que estarle pidiendo=
 al
>  > >kernel m=E1s y m=E1s pedazos de memoria, lo cual toma bastante tiem=
po (ya
>  > >conoces la afici=F3n de Windows de 'thrashear' con la memoria virtu=
al). En
>  > >los Unixes que conozco, el manejo de memoria es mucho m=E1s limpio =
y
>  > >eficiente.
>  >=20
>  >     Pos quien sabe, yo creo que esta mal el PERL para Windows... deb=
eria de
>  > matar el FileHandle con el close. Si fuera de Windows, se tardar=EDa=
 igual
>  > aunque trasheara la memoria.
>  > ...
>  >  open(my $FileHandle,$_[0]) || die "$_[0]: $!";
>  >  my @FileData =3D <$FileHandle>;   #Aqui esta la bronca...
>  >  close($FileHandle);
>=20
> No hab=EDa yo entendido bien. Por lo que veo, si tiene que ver con lo
> que dice Gunner de la memoria. La bronca no es si se cierra el
> FileHandle, es que lees todo el arvhivo a memoria. Cuando terminas de
> procesarlo, perl no necesariamente libera la memoria que ocup=F3 para
> los datos, de modo que, cuando lees el siguiente, necesita reservar
> m=E1s memoria. Y luego m=E1s para el siguiente. Verifica que tus variab=
les
> esten saliendo de contexto. Y que no estes usando 'closures'
> escondidas por ah=ED, por que eso hace que las referencias no se
> pierdan. No me acuerdo mero cual es la bronca de &funcion(), pero
> quitale el &, por si las dudas.
>=20
>=20