[Home] [Help]
76: * necessarily even supportable in stores. Simple scalar types
77: * (numbers, dates, timestamps, etc.) can be depended on by clients
78: * and must be implemented by stores.
79: *
80: * Since standard RDBMS typecodes are positive integers, the DBFS
81: * API allows negative integers to represent client-defined types by
82: * negative typecodes. These typecodes do not conflict with standard
83: * typecodes, and will be persisted and returned to the client as
84: * needed, but need not be interpreted by the DBFS API or any
78: * and must be implemented by stores.
79: *
80: * Since standard RDBMS typecodes are positive integers, the DBFS
81: * API allows negative integers to represent client-defined types by
82: * negative typecodes. These typecodes do not conflict with standard
83: * typecodes, and will be persisted and returned to the client as
84: * needed, but need not be interpreted by the DBFS API or any
85: * particular store. Portable client applications should not use
86: * user-defined typecodes as a backdoor way of passing information
184: *
185: *
186: * feature_acls:
187: * Set if the store supports "access control lists" and internal
188: * authorization/checking based on these acls. Acls are standard
189: * properties (see below), but a store may do nothing more than
190: * store and retrieve the "acls" without interpreting them in any
191: * way.
192: *
438:
439:
440:
441: /*
442: * Standard properties:
443: *
444: * Standard properties are well-defined, mandatory properties
445: * associated with all pathames that all stores should support (in
446: * the manner described by the DBFS API), with some concessions
440:
441: /*
442: * Standard properties:
443: *
444: * Standard properties are well-defined, mandatory properties
445: * associated with all pathames that all stores should support (in
446: * the manner described by the DBFS API), with some concessions
447: * (e.g. a read-only store need not implement a "modification_time"
448: * or "creation_time"; stores created against tables with a
448: * or "creation_time"; stores created against tables with a
449: * fixed-schema may choose reasonable defaults for as many of these
450: * properties as needed, etc.).
451: *
452: * All standard properties informally use the "std:" namespace.
453: * Clients and stores should avoid using this namespace to define
454: * their own properties since this can cause conflicts in future.
455: *
456: * The menu of standard properties is expected to be fairly stable
452: * All standard properties informally use the "std:" namespace.
453: * Clients and stores should avoid using this namespace to define
454: * their own properties since this can cause conflicts in future.
455: *
456: * The menu of standard properties is expected to be fairly stable
457: * over time.
458: *
459: *
460: * std_access_time (TYPECODE_TIMESTAMP in UTC):
460: * std_access_time (TYPECODE_TIMESTAMP in UTC):
461: * The time of last access of a pathname's contents.
462: *
463: * std_acl (TYPECODE_VARCHAR2):
464: * The access control list (in standard ACL syntax) associated
465: * with the pathname.
466: *
467: * std_canonical_path (TYPECODE_VARCHAR2):
468: * The canonical store-specific pathname of an item, suitably
476: * has (this property should be available in providers that
477: * support the "feature_folders" feature).
478: *
479: * std_content_type (TYPECODE_VARCHAR2):
480: * The client-supplied mime-type(s) (in standard RFC syntax)
481: * describing the (typically type_file) pathname. The content type
482: * is not necessarily interpreted by the store.
483: *
484: * std_creation_time (TYPECODE_TIMESTAMP in UTC):
635: * is invoking the content access method for other reasons
636: * (pathname existence/lockability validation, data access, etc.)
637: *
638: * prop_std:
639: * Used when the client is interested in the standard properties;
640: * all standard properties are retrieved if this flag is
641: * specified.
642: *
643: * prop_opt:
636: * (pathname existence/lockability validation, data access, etc.)
637: *
638: * prop_std:
639: * Used when the client is interested in the standard properties;
640: * all standard properties are retrieved if this flag is
641: * specified.
642: *
643: * prop_opt:
644: * Used when the client is interested in the optional properties;
650: * properties; all user-defined properties are retrieved if this
651: * flag is specified.
652: *
653: * prop_all:
654: * An alias for the combination of all standard, optional, and
655: * user-defined properties.
656: *
657: * prop_data:
658: * Used when the client is interested only in data access, and
1374: *
1375: * To allow for the DBFS API itself to evolve, an internal API
1376: * version will count up with each change to the public API.
1377: *
1378: * A standard naming convention will be followed in the version
1379: * string:
1380: * components.
1381: *
1382: */
2006: /*
2007: * Directory listings.
2008: *
2009: * A "path_item_t" is a tuple describing a (store, mount) qualified
2010: * path in a store, with all standard and optional properties
2011: * associated with it.
2012: *
2013: * A "prop_item_t" is a tuple describing a (store, mount) qualified
2014: * path in a store, with all user-defined properties associated with
2422: * lob passed in, the checker does not provide any useful indication
2423: * of the analysis (other than raise exceptions if it encounters a
2424: * serious error).
2425: *
2426: * If "schema_name" is "null", standard name resolution rules
2427: * (current schema, private synonym, public synonym) are used to try
2428: * and locate a suitable package to analyze.
2429: *
2430: * This is a helper wrapper around
2478: * disappear at any time becaue of a change in the DBFS state.
2479: * Clients must treat errors during view access as a signal to
2480: * refresh their own state (perhaps, re-invoking this method to
2481: * figure out the new view names, etc.) before proceeding, or else
2482: * fall back to using standard DBFS methods for their lookup
2483: * operations.
2484: *
2485: *
2486: * Also note that the getattr view need not (and will most likely