Current Page:
NeXtMidas Training
Primitives
Files in a Primitive
A Note About Files
|
|
- Important Note:
- The past few slides have shown the most common ways of accessing frame-based
and record-based data.
- NeXtMidas provides alternative methods that may be more appropriate to
a given situation.
FILE COPY treats all files as simple binary ones and
uses byte-based read and write methods.
- It is possible to treat most frame-based data as record-based and
record-based as frame-based.
LIST2 treats all data as record-based (listing is
an inherently record-based activity).
NOOP treats all data as frame-based (simplifies
this primitive and improves copy speed).
- See the DataFile API
for more examples of modifying/writing frame and record-based data.
Don't Make This Mistake: |
- Do not forget to close your input/output files in your primitive's
close
method, otherwise not all data may be written or your primitive may be holding on
to resources that it no longer needs, causing a "resource/memory leak".
- Additionally, you should check if your file is null otherwise you may get a
NullPointerException.
public int close() {
if (outfile!=null) {
outfile.close();
}
}
|
Java Experts Take Note: |
File offsets and sizes are of type double . There are two reasons for this:
- It allows bit indexing (fractional part indicates bit in byte) for frame-based data.
- It is consistent with the definition of Midas Blue files. (The definition of a
Blue file pre-dates widespread support for 64-bit integers, and the only way
to support file size larger than 2GB was to use a
double .)
Many new applications/primitives (like LIST2) that work with record-based data
internally store row numbers as a long and cast it to double
when reading/writing (this prevents the user from entering a fractional record number).
|
|
|
|