arsperl-users

[Arsperl-users] Get schema id from form name without arschema

[Franklin L. <ars...@le...>]

Is there any way to find the schema Id of a form given the form's name 
_without_ doing an explicit SELECT query against the arschema table? In 
other words, is the mapping stored somewhere besides the arschema table?

Re: [Arsperl-users] Get schema id from form name without arschema

[jeff m. <jcm...@je...>]

As far as I know, that's the only way.

jeff

On Nov 25, 2008, at 6:02 PM, Franklin Lee wrote:

> Is there any way to find the schema Id of a form given the form's name
> _without_ doing an explicit SELECT query against the arschema table?  
> In
> other words, is the mapping stored somewhere besides the arschema  
> table?

Re: [Arsperl-users] Get schema id from form name without arschema

[Carey M. B. <bla...@gm...>]

Franklin Lee,

Depending on your ARS version, you could create an ARS View form over
the arschema table and then use "normal" ARS API queries to get at the
data.

FWIW: The schemaId is viewed as a "local implementation detail" that
really should be transparent to the ARS developers and/or users. Which
leads to this question....

Why do you need to know the schemaId?

I ask because there might be other ways you could achieve your goals.

-- 
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.


On Tue, Nov 25, 2008 at 6:02 PM, Franklin Lee <ars...@le...> wrote:
> Is there any way to find the schema Id of a form given the form's name
> _without_ doing an explicit SELECT query against the arschema table? In
> other words, is the mapping stored somewhere besides the arschema table?

Re: [Arsperl-users] Get schema id from form name without arschema

[Franklin L. <ars...@le...>]

I can, by querying against the field table, get field information such 
as fOption and default value for all the fields in a given form. To do 
this, I need the schema id.

Is there any other way to get this information without knowing the 
schema id?


Carey Matthew Black wrote:
> Franklin Lee,
> 
> Depending on your ARS version, you could create an ARS View form over
> the arschema table and then use "normal" ARS API queries to get at the
> data.
> 
> FWIW: The schemaId is viewed as a "local implementation detail" that
> really should be transparent to the ARS developers and/or users. Which
> leads to this question....
> 
> Why do you need to know the schemaId?
> 
> I ask because there might be other ways you could achieve your goals.
> 

Re: [Arsperl-users] Get schema id from form name without arschema

[jeff m. <jcm...@je...>]

On Dec 1, 2008, at 12:45 PM, Franklin Lee wrote:

> I can, by querying against the field table, get field information such
> as fOption and default value for all the fields in a given form. To do
> this, I need the schema id.
>
> Is there any other way to get this information without knowing the
> schema id?
>



For default value, etc, I think getField() should return that  
information. You don't need the schema ID to use getField()


http://www.arsperl.org/manual/ds_field_hash.html

Re: [Arsperl-users] Get schema id from form name without arschema

[Franklin L. <ars...@le...>]

The getField function will get me field information on a _single_ field. 
But what if I want to get field information on _all_ the fields in a 
form at once.

I could, of course, call getField multiple times, but that seems very 
inefficient.

What I need is an ARSPerl version of ARGetMultipleFields. Does such an 
ARSPerl function exist?



jeff murphy wrote:
> On Dec 1, 2008, at 12:45 PM, Franklin Lee wrote:
> 
>> I can, by querying against the field table, get field information such
>> as fOption and default value for all the fields in a given form. To do
>> this, I need the schema id.
>>
>> Is there any other way to get this information without knowing the
>> schema id?
>>
> 
> 
> 
> For default value, etc, I think getField() should return that  
> information. You don't need the schema ID to use getField()
> 
> 
> http://www.arsperl.org/manual/ds_field_hash.html
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> --
> Arsperl-users mailing list
> Ars...@ar...
> https://lists.sourceforge.net/lists/listinfo/arsperl-users

Re: [Arsperl-users] Get schema id from form name without arschema

[Carey M. B. <bla...@gm...>]

Franklin Lee,

Note: This post may sound "negative" towards ARSPerl. It is not
intended to be. My understanding of ARSPerl's reach and range may be
limited as I have not seriously used it for some time now. ( FWIW: I
have moved on to the Java API. ) I do still use it some, for the tasks
that it is "best suited" for, but I have often found limits in my
abilities to use the wrapper to do "complex tasks" with ARSystem.


In general, I have often found that people that I will call "true
programmers" look at the ARS api and are left scratching their heads
over the choices that were made when the api was being laid out.

To be clear, what you think of as "inefficient" may not be as bad as
you think. (And there maybe options that ARSPerl simply does not yet
implemented, or exposed to it's users too.)

FWIW: The C and Java api's support a great deal of granularity as to
the level of details that you can get about the objects in the get*
api calls. So you do not have to get all of the field details when all
you want is the "fOption" settings for all of the fields. Yes you do
have to make a trip to the server for every field. However that is
simply because there are no advantages for the vendor (Remedy, and now
BMC Remedy) to have a single API call that returns that specific range
of details for all fields on a single Form or even "All Forms on a
server" for that matter.

I am however, unclear if the ARSPerl wrapper around the C API offers
the ability to limit the details that will be fetched for the
ars_GetField call. (It looks like there are no inputs to achieve that
goal.) For that matter I can not tell if ARSPerl has implemented the
ARGetMultipleFields API call either. The published HTML docs do not
appear to reference theARGetMultipleFields function specifically. In
fact the HTML docs give the impression that ars_GetFieldTable
specifically uses "ars_GetListField and ars_GetField". But I must add
that it is possible that the ARSPerl wrapper does include a way to
call the underpinning C ARGetMultipleFields API and it may not be
documented yet too.

You may also find that getting all details about a form will produce
the data set you need. However, you may need to walk the data returned
in ways that are not provided by the ARS API too.

The AR System is a 3 tiered system. Client, Server, and RDBMS. The
vendor has made decisions about that tasks will be done by each of
those layers for their own reasons. (And there is no written
explanation that I have ever come across.)

Often programmers expect the Server (ALA: ARS API ) to do things that
I believe were deemed to be the responsibility of the client layer.
(There are many examples, not the least common of which has to do with
desires to programmaticly dissect, construct, or manipulate ARS
objects in mass. Which are generally not implemented in the provided
clients. Even when they are simulated in the provided clients I
greatly suspect they are simply looping over the objects selected and
calling multiple single get/set/create API calls for each one.)
However, over they years as the AR System application reach and range
improved the ARGetMultiple* API calls were added to help with some
(not all) of these needs that the vendor started to face for their own
clients functionality.

Please keep in mind that while the AR System API is expose to the
customer that I have long believed that its design and purpose is very
vendor centric. The gaps may be there simply because the vendor does
not have the same needs, or they might be there to intentionally leave
gaps that make it harder for customers to totally replace the vendors
clients. ( You can reach either conclusion easily and likely can find
"evidence" to support both positions fairly easily.)

But long story short...

So as a wise teacher often says.... The rest is left to the student
(er.. Client in this case) to implement.

If you speak Java, you should will find the Java API to be more
complete. (and in theory, "supported" directly by the vendor.)

I hope some of that helps.

-- 
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.


On Mon, Dec 1, 2008 at 2:02 PM, Franklin Lee <ars...@le...> wrote:
> The getField function will get me field information on a _single_ field.
> But what if I want to get field information on _all_ the fields in a
> form at once.
>
> I could, of course, call getField multiple times, but that seems very
> inefficient.
>
> What I need is an ARSPerl version of ARGetMultipleFields. Does such an
> ARSPerl function exist?
>
>
>
> jeff murphy wrote:
>> On Dec 1, 2008, at 12:45 PM, Franklin Lee wrote:
>>
>>> I can, by querying against the field table, get field information such
>>> as fOption and default value for all the fields in a given form. To do
>>> this, I need the schema id.
>>>
>>> Is there any other way to get this information without knowing the
>>> schema id?
>>>
>>
>>
>>
>> For default value, etc, I think getField() should return that
>> information. You don't need the schema ID to use getField()
>>
>>
>> http://www.arsperl.org/manual/ds_field_hash.html
>>
>> --
>> Arsperl-users mailing list
>> Ars...@ar...
>> https://lists.sourceforge.net/lists/listinfo/arsperl-users

Re: [Arsperl-users] Get schema id from form name without arschema

[Thilo S. <thi...@ap...>]

Carey,

your post didn't sound negative towards ARSperl. Even if it did, your 
feedback would still be welcome.

Maybe I'm able to shed some light on the issues that you have addressed. 
ARSperl does indeed not implement any of the ARGetMultiple* calls, with 
the notable exception of ARGetMultipleEntries. Nor is it possible to 
limit the ars_Get* functions to specific attributes (again with the 
exception of ars_GetEntry). The reason for this is that the developent 
of ARSperl, like the ARS API itself, is somehow quite "vendor centric", 
the "vendor" in this case being a group of volunteers, especially 
myself. To state it more directly: if I need something, then I'll 
implement it.

The ARGetMultiple* functions don't have very high priority from my point 
of view, since their functionality is already provided by the 
ars_GetList*, ars_Get* functions, so it's only a matter of performance. 
Of course perforance is important, but the sort of programs for which I 
would use the ARGetMultiple* functions (e.g. creating a report of  all 
fields in an application) usually don't require that much performance. 
If it runs maybe only once a week, then it's okay if it takes a few 
minutes. Please note also, that for entries, where permormace is 
probably the most important, there are ars_GetMultipleEntries, 
ars_GetListEntryWithFields as well as ars_BeginBulkEntryTransaction and 
ars_EndBulkEntryTransaction.

Another reason is that we rather seldom hear from users about 
shortcomings or desired features, so again every feedback will be 
welcome. I'd be quite interested what the "complex tasks" where for 
which ARSperl eventually turned out to be too limited.

The ability to limit ars_GetWhatever() attributes is something which 
I've wanted myself sometimes, so this has a relatively high priority for 
me, at least concerning fields. The performance of ars_GetFieldTable, 
which is also used to populate the internal field cache (necessary to 
build the ARS API data structures for ars_CreateEntry/ars_SetEntry 
calls) would probably be much better if it used ARGetMultipleEntries. 
I'm currently working on this, so it will be definitely  implemented in 
the next release.


Thilo Stapff


Carey Matthew Black wrote:
> Franklin Lee,
> 
> Note: This post may sound "negative" towards ARSPerl. It is not
> intended to be. My understanding of ARSPerl's reach and range may be
> limited as I have not seriously used it for some time now. ( FWIW: I
> have moved on to the Java API. ) I do still use it some, for the tasks
> that it is "best suited" for, but I have often found limits in my
> abilities to use the wrapper to do "complex tasks" with ARSystem.
> 
> 
> In general, I have often found that people that I will call "true
> programmers" look at the ARS api and are left scratching their heads
> over the choices that were made when the api was being laid out.
> 
> To be clear, what you think of as "inefficient" may not be as bad as
> you think. (And there maybe options that ARSPerl simply does not yet
> implemented, or exposed to it's users too.)
> 
> FWIW: The C and Java api's support a great deal of granularity as to
> the level of details that you can get about the objects in the get*
> api calls. So you do not have to get all of the field details when all
> you want is the "fOption" settings for all of the fields. Yes you do
> have to make a trip to the server for every field. However that is
> simply because there are no advantages for the vendor (Remedy, and now
> BMC Remedy) to have a single API call that returns that specific range
> of details for all fields on a single Form or even "All Forms on a
> server" for that matter.
> 
> I am however, unclear if the ARSPerl wrapper around the C API offers
> the ability to limit the details that will be fetched for the
> ars_GetField call. (It looks like there are no inputs to achieve that
> goal.) For that matter I can not tell if ARSPerl has implemented the
> ARGetMultipleFields API call either. The published HTML docs do not
> appear to reference theARGetMultipleFields function specifically. In
> fact the HTML docs give the impression that ars_GetFieldTable
> specifically uses "ars_GetListField and ars_GetField". But I must add
> that it is possible that the ARSPerl wrapper does include a way to
> call the underpinning C ARGetMultipleFields API and it may not be
> documented yet too.
> 
> You may also find that getting all details about a form will produce
> the data set you need. However, you may need to walk the data returned
> in ways that are not provided by the ARS API too.
> 
> The AR System is a 3 tiered system. Client, Server, and RDBMS. The
> vendor has made decisions about that tasks will be done by each of
> those layers for their own reasons. (And there is no written
> explanation that I have ever come across.)
> 
> Often programmers expect the Server (ALA: ARS API ) to do things that
> I believe were deemed to be the responsibility of the client layer.
> (There are many examples, not the least common of which has to do with
> desires to programmaticly dissect, construct, or manipulate ARS
> objects in mass. Which are generally not implemented in the provided
> clients. Even when they are simulated in the provided clients I
> greatly suspect they are simply looping over the objects selected and
> calling multiple single get/set/create API calls for each one.)
> However, over they years as the AR System application reach and range
> improved the ARGetMultiple* API calls were added to help with some
> (not all) of these needs that the vendor started to face for their own
> clients functionality.
> 
> Please keep in mind that while the AR System API is expose to the
> customer that I have long believed that its design and purpose is very
> vendor centric. The gaps may be there simply because the vendor does
> not have the same needs, or they might be there to intentionally leave
> gaps that make it harder for customers to totally replace the vendors
> clients. ( You can reach either conclusion easily and likely can find
> "evidence" to support both positions fairly easily.)
> 
> But long story short...
> 
> So as a wise teacher often says.... The rest is left to the student
> (er.. Client in this case) to implement.
> 
> If you speak Java, you should will find the Java API to be more
> complete. (and in theory, "supported" directly by the vendor.)
> 
> I hope some of that helps.
> 

Re: [Arsperl-users] Get schema id from form name without arschema

[G. D. F. <gd...@ui...>]

Thilo Stapff wrote:
> Maybe I'm able to shed some light on the issues that you have addressed. 
> ARSperl does indeed not implement any of the ARGetMultiple* calls, with 
> the notable exception of ARGetMultipleEntries. Nor is it possible to 
> limit the ars_Get* functions to specific attributes (again with the 
> exception of ars_GetEntry). The reason for this is that the developent 
> of ARSperl, like the ARS API itself, is somehow quite "vendor centric", 
> the "vendor" in this case being a group of volunteers, especially 
> myself. To state it more directly: if I need something, then I'll 
> implement it.

Hey, I can provide some background here, because I'm one of those
volunteers, and I implemented GetMultipleEntries and GetListEntryWithFields.

The way most ARSperl applications work, in my experience, is that there is
an initialization phase where one-time information is pulled from the
server, followed by a data-intensive phase that might involve repeated
queries and data retrievals.  Life in ARSperl before those two functions
was tedious and in my world I was dealing with significant performance
issues.  The improvement was dramatic.

Not so important, in my mind, was the need to pull field definitions.  A
one-time charge to loop through the fields you want isn't so bad.  And
while the data changes every day, the field definitions don't.  I finally
canned ALL of the field queries in favor of a periodic "information
gathering" script that does the queries and preserves the results with
Data::Dumper so every script can retrieve them when needed.  I know it
helps that I had complete control over our ARS implementation so if
something changed, I could update the definitions immediately.  That's
not so different from what Remedy User does with caching schema files,
after all.

-- 
G. David Frye
gd...@ui...
(217)840-0570

Re: [Arsperl-users] Get schema id from form name without arschema

[Michiel B. <mi...@be...>]

Franklin,

If you want to solve this by hacking and slashing in the database, you
can query against the arschema table.

Try this:

SELECT field.* from arschema, field
where name = '<name from form>'
and arschema.schemaid = field.schemaid

Of course this gets you in the position where you would need to know
the schema name as held in the database, and that is not the same as
the schema ALIAS. HPD:Helpdesk is HPD_HELPDESK or the like. The
benefit is that this is (or at least: is supposed to be) consistent
between installations, i.e. the names will not vary between for
instance different installs of ITSM 7, whereas the schema IDs of
course can differ a lot; also between Production - Acceptance - Test -
Development boxes schema ID's will most probably very a lot.

In my opinion it is always a sign of bad code if the schema ID is
hardcoded anywhere, it should always be looked up first, either using
a query on ARSCHEMA or via an API call.

Regards,
-- 
Michiel Beijen
Software Consultant
+31 6 - 457 42 418
Bee Free IT + http://beefreeit.nl




On Mon, Dec 1, 2008 at 6:45 PM, Franklin Lee <ars...@le...> wrote:
> I can, by querying against the field table, get field information such
> as fOption and default value for all the fields in a given form. To do
> this, I need the schema id.
>
> Is there any other way to get this information without knowing the
> schema id?
>
>
> Carey Matthew Black wrote:
>> Franklin Lee,
>>
>> Depending on your ARS version, you could create an ARS View form over
>> the arschema table and then use "normal" ARS API queries to get at the
>> data.
>>
>> FWIW: The schemaId is viewed as a "local implementation detail" that
>> really should be transparent to the ARS developers and/or users. Which
>> leads to this question....
>>
>> Why do you need to know the schemaId?
>>
>> I ask because there might be other ways you could achieve your goals.
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
>
> --
> Arsperl-users mailing list
> Ars...@ar...
> https://lists.sourceforge.net/lists/listinfo/arsperl-users
>