Feature Requests item #872236, was opened at 2004-01-07 10:16 Message generated for change (Settings changed) made by mr-meltdown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482471&aid=872236&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Martin Kersten (mlkersten) Assigned to: Nobody/Anonymous (nobody) >Summary: SQL: better BLOB protocol support Initial Comment: The Blob module has been developed 8 years ago as a first attempt to exercise the MEL facilities. The way it was implemented reflected the then to time approach to manage all data within the confines of a DBMS. For Blobs this meant effectively mimicking a file-service. With the ubiquitious availability of HTTP services it makes sense to drastically redesign the blob interface along the following lines. Assumption 1. A URL module is already available to manage strings satisfying the URL conventions. Assumption 2. Blobs are 'ordinary data items' brought under the control of the DBMS Assumption 3. Blobs find their origin in the local file system or in remote web-space. The Blobs can now be managed by the DBMS as follows. Next to the dbfarm directory for retaining the persistent data, a directory is created in the space managed by e.g. an Apache server. The location of which is handed to the Blob module upon initialization. Let's call it .../MonetDB/BlobStore Blobs are inserted into the DBMS by providing an url handle, e.g. the following should work: b:= new(int, blob); b.insert(1,"http://www.cwi.nl/~mk/index.html";); b.insert(2,"file:///tmp/x"); Upon transaction commit (or anytime earlier as needed) the blob objects are obtained and assigned a location in the BlobStore using an internally generated name. The BlobStore could be organized as a cache, e.g. multiple directories to spread the load. The Blob interface maintains the mapping from the original handle to the location in its own store. Furthermore, a reference count should be maintained to guarantee accessibility over multiple assigments. The operations defined over an Blob items become: getOrigin - returns the source handle clrOrigin - forget the source handle getHandle- return url to enable access The mapping between handle and physical location can be changed by the DBMS at will. Their is no guarantee that the handle given to a user is likely to last forever. This Blob mechanism can be readible extended to handle images, video, audio, etc.. They merely require some additional test on the content type and probably need more space. The expected implementation effort is considered 1-2 days, provided we can easily include the HTTP access protocol software inside the Mserver to retrieve the Blobs in the first place from the application environment. ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2004-09-09 11:22 Message: Logged In: YES user_id=963970 the Mapi protocol should handle BLOBs and TEXTs (which could/should be very large) as special urls, which can be retrieved by the mapi client and returned to the user as blob. This meets requirements made by for instance JDBC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482471&aid=872236&group_id=56967 ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
