Le 30/08/2011 16:51, Nate Coraor a écrit :
Louise-Amélie Schmitt wrote:
I just changed it and ran into an error, so I modified the line and
it now works fine:
$__app__.security.encode_id( '%s' % $input1.id )
What was the 'file.' originally for?
On the API side, a library or history's "contents" are all identified by
ID, so:

     http://server/api/libraries/<library_id>/contents/<content_id>

That content ID can refer to a dataset (file) or folder, but if this was not
'file.<id>' or 'folder.<id>', when the framework decoded it, it would just get
a numeric ID and wouldn't know to which type it refered.  So instead of using
just the ID, it uses the encoded form of 'file.<id>' and 'folder.<id>'.  This
was extended to histories even though there isn't a concept of folders in
histories.

So just encoding the ID is going to give you the encoded
HistoryDatasetAssociation id, but that ID won't be the dataset's API id.
For example, using the default id_secret in universe_wsgi.ini, if I
upload a dataset to a fresh instance of Galaxy, its encoded ID (the
encoded value of '1') is:

     f2db41e1fa331b3e

As you can see in the 'display' URL for the dataset:

     http://server/datasets/f2db41e1fa331b3e/display/

But that ID won't work for the history API:

     % ./display.py<key>  http://server/api/histories/f597429621d6eb2b/contents
     Collection Members
     ------------------
     #1: /api/histories/f597429621d6eb2b/contents/cc1c6c1afcb4fd4e
       name: 1.bed
       type: file
       id: cc1c6c1afcb4fd4e

f597429621d6eb2b is the encoding of '2' with the default id_secret since this
dataset is in history ID 2.  cc1c6c1afcb4fd4e is the encoding of 'file.1'.

--nate

This really confuses me. I'll try to explain why:

I have a script that runs two workflows one after the other. The ids in the results of workflow 1 are stored in a database, along with some parameters for workflow 2.

Then, I run workflow 2 on workflow 1's results. In this workflow I have a tool that queries the database to get the parameters it needs, so it compares the input ids with those stored previously.

If I use this line:

$__app__.security.encode_id( 'file.%s' % $input1.id )

It does not match the output ids of workflow 1, so I cannot access the corresponding parameters.
But if I use this:

$__app__.security.encode_id( '%s' % $input1.id )

the ids match and I get the appropriate database entry.

What I understood of it:
There must be something wrong somewhere, since I'm clearly manipulating "file." free stuff and it works just fine. Those same ids are passed to workflow 2 and it runs properly, on the appropriate datasets.

Did I miss anything? Did I do something wrong?

L-A



Le 24/08/2011 15:00, Louise-Amélie Schmitt a écrit :
Thanks a lot!

I found another way to do it but it is awfully more complicated so
I'll change as soon as I have some time.

Best,
L-A


Le 23/08/2011 19:49, Nate Coraor a écrit :
Louise-Amélie Schmitt wrote:
Hi,

I would need to make a tool that can get the API dataset id out of
the input dataset of the tool, how can I do that?
Hi L-A,

Pass in as an argument:

     $__app__.security.encode_id( 'file.%s' % $input1.id )

Where 'input1' is the param name of your input.

--nate

___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/


___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

 http://lists.bx.psu.edu/

Reply via email to