I saw in the flaws.txt on GitHub that the SQLReader currently lacks any mechanism to retrieve the ContentType from the database.
My database lets users store various types of images and files in the DB and the content type is always stored with the file.
I'm interested in trying to resolve this, but am kind of not sure where to start. I've worked my way through the existing SQLReader and BlobProviderBase but can't seem to find a way to even pass the content type back up the chain.
Any thoughts?
Related
We store uploaded files in Documentum and in the event someone uploads files with the same name, we would like to be able to retrieve the correct file using the Rest API.
We store metadata (filename, etc.) in the database as part of a queue of work. So a user will go in and pick the next item in the queue (in this case look at the uploaded file). Currently we look up using the filename and return the first file which is not ideal.
I know you get the Document back (including object id) upon upload, and I was thinking about storing that along with the other metadata, and we can compare that, but I stumbled across an article suggesting this was a bad idea.
I'm new to Documentum, so how do others manage this?
The referenced article is correct. Using of r_object_id for external references is not good idea especially because of the possible future migration. Because r_object_id contains the docbase ID and when you migrate into a new docbase then all documents will have different r_object_id.
You can solve it by adding of a custom attribute to the document type, where you can store copy of the r_object_id value (can be implemented by TBO) or generate your own ID (it can be also implemented by TBO or DB sequence), when the attribute is not filled in yet. Then you can use this value as a unique reference to that uploaded document.
And when you migrate into another docbase in the future r_object_id will change but value of that custom attribute will still remain the same.
I can import Comma Separated Values (CSV) data through the admin pages, into most models. This process handles the external IDs so that the data can be added to or amended as appropriate in later CSV imports. This is a manial action.
Through the API, the same records can be created and amended, and external IDs can be set. This, however, requires a lot of the logic that would otherwise be handled by the CSV importer to be coded by hand, in the external application that uses the API to push in data. Pushing data through the API can be automated.
Is there a way the API can be used (so no changes need to be made to code within Odoo) to push CSV data (so the logic for insert/update/relationships/external IDs/ etc. is handled by Odoo)? This would be a kind of hybrid approach, and I am trying to avoid the need to create import modules within Odoo.
Edit: the "external ID" is often called the "XML ID". I think it is a terminology that has stuck from earlier versions of OpenERP, rather than having anything specific to do with XML.
Edit
This page describes a load() function that pushes CSV-like data through a pipeline to load it into the system:
http://openerp-server.readthedocs.org/en/latest/06_misc_import.html
I can't see how to translate the summary on that page into an operation through the API, if indeed that is possible. I'm guessing I will need the interface (entry point), model, method (load(), probably), and some additional parameters, but the details are beyond me.
The answer is kind of "yes".
The load() method can be used against any model to load data. This method takes data in the same structure as a CSV file would provide.
The first parameter is an array of field names, like the column headings on a CSV import.
The second parameter is an array of records. Each record is an array of values matching each field.
The API will return a list of errors where they are catered for by OpenERP. Many errors, however, just result in database exceptions on OpenERP and so need to be picked up as an API failure. This is largely because the OpenERP API is not designed as a generic API, but as a part of the GUI, and so the data sent to the API is very much bound to the current state of the application through that GUI. In other words, invalid data will seldom find its way to the API using the OpenERP GUI.
I have wrapped the loader functionality, catching errors and exceptions, in my PHP OpenERP API library here:
https://github.com/academe/openerpapi/blob/master/src/App/Loader.php
Hopefully that will be useful to others too.
I think the answer is "no".
However, this technique has been explained to me:
Create a module with little in it but CSV files for importing.
Install the module.
When a new CSV file needs to be imported, transfer it into the module (FTP or similar).
Once transferred, run the update() method for the module. This can be done through the API.
The update method will scan and load all the CSV files set up within the module. Care needs to be taken to make sure only one upload/update transaction will be run at any time.
I'll post additional details here when I have got this working, or will happily accept an alternate answer if there is a better way to handle this.
I have a Search web reference (from a Search Server 2010 express install) in a vb.net application that is utilizing the QueryService Class to search a production Sharepoint foundation 2010 site.
At a previous point in time, we had created a proof of concept on an entirely test system that has since been turfed. From my recollection on this test system when documents were uploaded as a specific site content type (that inherits from document) and metadata was provided, we could search for specific metadata by making managed properties for each, and search results would be returned as documents (with the isdocument flag set to true). Viewing the document then became simple, as we could simply use the filename and path to display the stored file.
Now we are developing a production system and we have encountered a new behavior, where these results now are returned as aspx results such as
http://digitizaton/Company/Client Documents/Forms/DispForm.aspx?ID=1703
This of course makes it terribly difficult to locate and view the document, we can extract the Title which will then give us the name of the file with no extension, but that hardly helps, as the FileExtension data is aspx, not the documents file extension, so we don't have a full filename. We could display the page returned as a result, but would much prefer the document itself.
I've made a test document library, with just bare bones setup, (not using the site content type, or site columns) and uploaded some documents on the same site, and they are returned in the same fashion, so I don't believe the document library, or content type are the issue.
With a fairly limited understanding of both Sharepoint and Search Server, I don't know if this is a setup issue with the search service itself, with the site configuration, or with the querypacket I am sending. We also have a third party application (Knowledgelake) installed on the server that ties into sharepoint which could have changed configuration somewhere as well?
I don't think the query packet has changed since it was working in the proof of concept, other than the custom data column names. I will provide it here in case there is something glaringly obvious to an external reader.
<QueryPacket xmlns='urn:Microsoft.Search.Query.Document'>"
<Query>
<SupportedFormats>
<Format>urn:Microsoft.Search.Response</Format>
</SupportedFormats>
<Range>
<Count>0</Count>
</Range>
<Context>
<QueryText type='MSSQLFT'>
SELECT Filename, Title, FileExtension, IsDocument, Path from Scope() WHERE ""Scope"" = 'Department1' AND CustomData = 'X' --
</QueryText>
</Context>
Any guidance would be incredibly appreciated. If I have not provided some relevant information, please let me know and I can track it down.
Thanks everyone
So now I feel like an idiot, I've searched for hours with no luck, and literally seconds after composing this post, I find the nugget of gold I've been searching for.
It appears that our primary file type, PDF, has a known issue with Sharepoint 2010, as shown at the following site.
http://www.sharepointsharon.com/2010/03/sharepoint-2010-and-adobe-pdf/
and further to that, this registry entry setting is required to link it all together
http://www.mossgurus.com/adnan/Lists/Categories/Category.aspx?Name=SharePoint%202010%20--%20Configuration
I'm writing an obj-c app and would like to upload a binary file a few megs in size to my appengine server (python). I'm guessing I need to use the blob entity for this, but am unsure how to go about doing this. I've been using http requests and responses to send and receive data up to now, but they've been encoded in strings. Can someone advise how I'd go about doing the same with blobs from an obj-c app? I see some examples that involve http requests but they seem geared toward web page and I'm not terribly familiar with it. Are there any decent tutorials or walkthroughs perhaps?
I'm basically not completely sure, if I'm supposed to encode it into the http request and send it back through the response, how to get the binary data into the http string from the client and how to send it back properly from the server when downloading my binary data. I'm thinking perhaps the approach has to be totally different from what I'm used to with encoding values into my request in the param1=val¶m2=val2 style format but uncertain.
Should I be using the blobstore service for this? One important note is that I've heard there is a 1 meg limit on blobs, but I have audio files 2-3 megs in size that I need to store (at the very least 1.8 megs).
I recently had to do something similar, though it was binary data over a socket connection. To the client using XML, to the server as a data stream. I ended up base64 encoding the binary data when sending it back and forth. It's a bit wordy but especially on the client side it made things easier to deal with, no special characters to worry about in my XML. I then translated it with NSData into a real binary format. I used this code to do the encoding and decoding, search for "cyrus" to find the snippet I used, there are a few that would work here.
In your case I would change your http request to a post data call rather than putting it all in the URL. If you're not sure what the difference is, have a look here.
I'm not as familiar with python, but you could try here for help on that end.
Hope that helps.
Edit - it looks like blobs are the way to go. Have a look at this link for the string/blob type as well as this link for more info on working with the blob.
There are three questions in one here:
Should you use a BLOB for binary data?
How do you post binary data, and use it from app engine
How do you retrieve binary data from app engine
I can't answer if you "should" use blobs, only you would know the answer to that, and it greatly depends upon the type of data you are trying to store, and how it will be used. Let's take an image for example (which is probably the most popular use case for this). You want users to take a photo with their phone, upload it, and then share it with other users. That's a good use of blobs, but as #slycrel suggests you'll run into limitations on record size. This can be workable, for example you could use the python image library (pil) to downsize the image.
To post binary data, see this question. It would be best to cache 2 copies, a thumbnail and a full size. This way the resizing only has to happen once, on upload. If you want to go one better, you can use the new background jobs feature of app engine to queue up the image processing for later. Either way, you'll want to return the ID of the newly created blob so you can reference it from the device without an additional http request.
To retrieve data, I think the best approach would be to treat the BLOB as it's own resource. Adjust your routes such that any given blob has a unique URL:
http://myweb/images/(thumbnail|fullsize)/<blobid>.(jpg|png|gif)
Where BLOBID is dynamic, and JPG, PNG or GIF could be used to get the particular type of image. Thumbnail or fullsize could be used to retrieve the smaller or larger version you saved when they posted it.
So, I have a bunch of HTML is being stored in a SQLite database, and they link back and forth amongst themselves. When a user clicks to follow a link, that request needs to be serviced by pulling the appropriate HTML out of the database. This could result in needing to load images, which are also being stored in the database (this is a future thing; there are no images yet, but I'd like to be able to use them). I've looked through the WebKit documentation, but can't quite figure out how to make this happen. I've mostly looked at WebFrameLoadDelegate and WebResourceLoadDelegate, but I didn't see one that would let me catch the request, grab the appropriate content, and then send that in a response.
Ideas? I'm pretty new to Objective-C and Cocoa, but I think I'm mostly getting the hang of things.
How do the pages which are stored in the database link to each other? It is probably easiest if they use some sort of customer URL scheme to start with.
The approach I would use is to implement
-webView:resource:willSendRequest:redirectResponse:fromDataSource:
in your resource load delegate. If the request is for a resource that is actually located in your database, return a new[1] NSURLRequest which uses a custom URL protocol which points to the database resource:
x-my-scheme:///table/row
[1] Unless you are already linking amongst your resources with the custom URL scheme - then you can skip this step.
Then, implement a custom NSURLProtocol for x-my-scheme which knows how to retrieve the data from the database. The PictureBrowser sample gives a simple example of how this is done.