A Wednesday 19 November 2008, Francesc Alted escrigué:
> Hi Milad,
>
> I've just received this message.  It seems that it bounced for some
> unknown reason.  Anyway, see my answer interspersed through your
> comments.
>
> > Message: 1
> > Date: Fri, 14 Nov 2008 11:05:05 -0600
> > From: "Milad Fatenejad" <[EMAIL PROTECTED]>
> > Subject: Re: [Pytables-users] pytables compatibility with h5tb
> > To: "Francesc Alted" <[EMAIL PROTECTED]>
> > Cc: pytables-users@lists.sourceforge.net
> > Message-ID:
> >        
> > <[EMAIL PROTECTED]>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hi Francesc:
> > Thanks for your reply. It is a big relief to know that the two
> > projects are designed to work with one another. Below, I've
> > included: 1) The pytables code to generate the hdf5 file, with one
> > record in the /streams/time table
> > 2) The c++ code which simply opens the file and appends two more
> > records.
>
> I've tracked down the problem in a bug in the HDF5's H5TB interface. 
> It seems that it does not honor the NROWS attribute in a consistent
> way throughout the calls in H5TB.  Apparently, it doesn't create a
> NROWS attribute in table creation time, but under some circumstances
> (for example, when deleting a row of the table), it gets eventually
> created. It happens that the routine that detects the number of rows
> in a table (H5TBget_table_info()) first looks at the NROWS existence,
> and if there, it trust it instead of asking directly to the dataset
> (with H5Sget_simple_extent_dims()).  However, it turns out that the
> function for appending rows (H5TBappend_records()), doesn't update
> properly the NROWS attribute, so you can't never increase the number
> of rows in successive appends.
>
> On his hand, PyTables always keep NROWS updated, so, this is why when
> you mix both ways of updating the HDF5 file this problem appears.
>
> I think this NROWS parameter comes from the age of pre-HDF5 1.8.x
> series, where the H5Dset_extent() did not work properly.  However, I
> think that it works as intended with HDF5 1.8.x, so an elegant
> solution for the problem would be to get rid of the NROWS attribute
> completely. If not, H5TB should be fixed in order to honor the NROWS
> where appropriate.
>
> I'll contact the THG crew about this and let you know their answer.

And here it is:

"""
Hi Francesc,

A bug report was created for this issue.  We will
re-examine the H5TB interface and update it as needed.

Thanks!
-Barbara


+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Barbara Jones
THG Helpdesk

The HDF Group (THG)
[EMAIL PROTECTED]
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
"""

Meanwhile, what you can do is to delete the NROWS attribute each time 
that you want to update a table from your C++ program.  That would make 
everything work as intended.

Another solution is that you set the PYTABLES_SYS_ATTRS to False in your 
parameters.py (or pass it as a keyword to the openFile() function).  
This prevents the NROWS (as well as all the other system attributes) to 
be written in PyTables generated files.  You will need PyTables 2.1 
(its final version is planned for the next week) for doing this though.

Cheers,

-- 
Francesc Alted

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Pytables-users mailing list
Pytables-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pytables-users

Reply via email to