JP2008217439A - テーブル操作用インタフェースプログラム - Google Patents
テーブル操作用インタフェースプログラム Download PDFInfo
- Publication number
- JP2008217439A JP2008217439A JP2007054118A JP2007054118A JP2008217439A JP 2008217439 A JP2008217439 A JP 2008217439A JP 2007054118 A JP2007054118 A JP 2007054118A JP 2007054118 A JP2007054118 A JP 2007054118A JP 2008217439 A JP2008217439 A JP 2008217439A
- Authority
- JP
- Japan
- Prior art keywords
- type
- value
- card
- user application
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
【課題】 テーブル毎に共通のインタフェースを提供することができる汎用性に優れたテーブル操作用インタフェースプログラム（ＡＰＩ）を提供すること
【解決手段】 ユーザアプリケーションプログラムから構造体のメンバ毎に１枚のカード型構造体により構成される複数のカード型構造体を受取り、その受け取った各カード型構造体に格納された型情報によって各メンバの値の格納サイズを計算し、計算結果のメンバ値を格納する構造体の格納領域を作成する第１の手段と、前記複数のカード型構造体のそれぞれで指定されたメンバ値を下位層のデータベース等から取得する第２の手段と、取得したメンバ値を前記第１の手段で作成した格納領域の構造体に格納し、前記ユーザアプリケーションプログラムに返す第３の手段とを備える。
【選択図】 図１
【解決手段】 ユーザアプリケーションプログラムから構造体のメンバ毎に１枚のカード型構造体により構成される複数のカード型構造体を受取り、その受け取った各カード型構造体に格納された型情報によって各メンバの値の格納サイズを計算し、計算結果のメンバ値を格納する構造体の格納領域を作成する第１の手段と、前記複数のカード型構造体のそれぞれで指定されたメンバ値を下位層のデータベース等から取得する第２の手段と、取得したメンバ値を前記第１の手段で作成した格納領域の構造体に格納し、前記ユーザアプリケーションプログラムに返す第３の手段とを備える。
【選択図】 図１
Description
本発明は、ユーザアプリケーションプログラムから任意のテーブルを操作するためのテーブル操作用インタフェースプログラム（テーブル操作用ＡＰＩ）に係り、特に、Ｃ言語の構造体を使用したテーブル操作用インタフェースプログラムに関するものである。
Ｃ言語のプログラム開発において、複数の項目を一度に扱う場合は、一般的に構造体を使用することが多い。しかし、構造体は型情報と名前情報しか持っておらず、各メンバがどの領域に配置されるのか確定されないため、不都合が生じることがある。
例えば、データベースで表されるデータの取得・設定を行うテーブル操作用ＡＰＩを考える。これは、ユーザアプリケーションプログラムとデータベース（以下、ＤＢと略記）を繋ぐ中継関数となる。ユーザアプリケーションプログラムは構造体を使用してデータの受け渡しを行い、ＤＢは構造体ではなくメンバごとの詳しい情報（型、サイズ、名前）を使う。
中継関数を用いた場合、実ＤＢに依存しないＡＰＩを作成することができ、またＤＢアクセス用の専用コマンド（ＳＱＬ等）を習得する必要が無い、などの利点が挙げられる。
ところが、このような中継関数を実装するためには、ユーザアプリケーションである上位層に構造体形式のデータを返却しなくてはならない。そのため、上位に返却する構造体の型を中継関数が予め知っていなくてはならない。つまり、任意の構造体に対応した汎用関数は作成できないこととなる。
例えば、データベースで表されるデータの取得・設定を行うテーブル操作用ＡＰＩを考える。これは、ユーザアプリケーションプログラムとデータベース（以下、ＤＢと略記）を繋ぐ中継関数となる。ユーザアプリケーションプログラムは構造体を使用してデータの受け渡しを行い、ＤＢは構造体ではなくメンバごとの詳しい情報（型、サイズ、名前）を使う。
中継関数を用いた場合、実ＤＢに依存しないＡＰＩを作成することができ、またＤＢアクセス用の専用コマンド（ＳＱＬ等）を習得する必要が無い、などの利点が挙げられる。
ところが、このような中継関数を実装するためには、ユーザアプリケーションである上位層に構造体形式のデータを返却しなくてはならない。そのため、上位に返却する構造体の型を中継関数が予め知っていなくてはならない。つまり、任意の構造体に対応した汎用関数は作成できないこととなる。
このような問題を踏まえ、従来においては、使用するテーブル、取得するデータごとにＡＰＩを持つＤＡＯ（Data Access Object）などが提案されている。これは、テーブル毎に専用のＡＰＩ（Application Programming Interface）を作成する仕組みである。
例えば、図６のような構成を持ち、ユーザアプリケーションプログラム６０１が直接にＤＢ依存Ｉｎｔｅｒｆａｃｅ６０４を呼び出すことを禁止する。代わりに、ＤＡＯクラス６０２と呼ばれるクラスをテーブル６０３ごとに自動生成し、ユーザアプリケーションプログラム６０１はＤＡＯクラス６０２のメソッドを経由してデータにアクセスする。こうすることでＤＢ層の実体が変わってもユーザアプリケーションプログラム６０１を変更することなく動作させることができる。
また、下記特許文献１のように、共通ＡＰＩを作成して下位レイヤを入れ替えられるようにした発明も提案されている。これもテーブルごとにＡＰＩの作成が必要であり、任意のテーブルに対応したものとはなっていない。
例えば、図６のような構成を持ち、ユーザアプリケーションプログラム６０１が直接にＤＢ依存Ｉｎｔｅｒｆａｃｅ６０４を呼び出すことを禁止する。代わりに、ＤＡＯクラス６０２と呼ばれるクラスをテーブル６０３ごとに自動生成し、ユーザアプリケーションプログラム６０１はＤＡＯクラス６０２のメソッドを経由してデータにアクセスする。こうすることでＤＢ層の実体が変わってもユーザアプリケーションプログラム６０１を変更することなく動作させることができる。
また、下記特許文献１のように、共通ＡＰＩを作成して下位レイヤを入れ替えられるようにした発明も提案されている。これもテーブルごとにＡＰＩの作成が必要であり、任意のテーブルに対応したものとはなっていない。
ＤＢから取得した値を上位層に返却するテーブル操作用ＡＰＩを作成する場合、従来はＤＡＯのような仕組みが使われていた。この仕組みでは、テーブルごとに新しいメソッドを定義する必要があり、テーブル毎に共通のインタフェースを提供することができないという問題がある。
本発明の目的は、テーブル毎に共通のインタフェースを提供することができる汎用性に優れたテーブル操作用インタフェースプログラム（ＡＰＩ）を提供することにある。
上記目的を達成するために、本発明に係るテーブル操作用インタフェースプログラム（以下、テーブル操作用ＡＰＩ）は、ユーザアプリケーションプログラムから構造体のメンバ毎に１枚のカード型構造体により構成される複数のカード型構造体を受取り、その受け取った各カード型構造体に格納された型情報によって各メンバの値の格納サイズを計算し、計算結果のメンバ値を格納する構造体の格納領域を作成する第１の手段と、前記複数のカード型構造体のそれぞれで指定されたメンバ値を下位層のデータベース等から取得する第２の手段と、取得したメンバ値を前記第１の手段で作成した格納領域の構造体に格納し、前記ユーザアプリケーションプログラムに返す第３の手段としてコンピュータを機能させるステップを備えることを特徴とする。
本発明のテーブル操作用ＡＰＩによれば、次の効果がある。
上位層のユーザアプリケーションプログラムはメンバ毎の構造体を用いてデータアクセスが可能となる。そのため、既存のシステムを壊すことなく、下位層の変更が可能となる。
ミドルウェア層では、上位で使用する構造体の形式を事前に決めることなく、任意の構造体を上位層から受け取ることができる。
上位層のユーザアプリケーションプログラムはメンバ毎の構造体を用いてデータアクセスが可能となる。そのため、既存のシステムを壊すことなく、下位層の変更が可能となる。
ミドルウェア層では、上位で使用する構造体の形式を事前に決めることなく、任意の構造体を上位層から受け取ることができる。
以下、本発明を図示する実施の形態に基づいて詳細に説明する。
図１は、本発明の一実施の形態を示すシステム構成図である。
この実施形態のシステムでは、移動体通信装置１１０上で動作するユーザアプリケーション１２０と、ＳＱＬを解釈できるＤＢ部１５０と、ＤＢ部１５０とユーザアプリケーション１２０を結ぶためのテーブル操作用ＡＰＩ１４０と、テーブル操作用ＡＰＩ１４０の中に組み込んだ構造体計算部１４１、構造体への値格納部１４２、値解析部１４３、ＤＢ制御部１４４と、ＤＢのファイルシステム１６０とを移動体通信装置１１０内のメモリ（図示しない）に備えている。
例えば、移動体通信装置の代表例である携帯電話機へ始めてデータベースを搭載することを考える。従来の携帯電話機用プログラムの開発ではデータベースを用いていなかった。そのため、上位層アプリケーションではアドレス帳、スケジューラなどのデータアクセスには構造体を用いている。一方、ＤＢでアクセスするためには、テーブル名、カラム名、カラムの型、サイズなど、細かい情報が必要になる。ＤＢをアクセスするための汎用ミドル関数を作成する場合には、どのようなテーブルでもアクセスできるよう、テーブル名、カラム名などのＤＢ情報を保持し、その情報を元に取得した値を上位層に返却しなくてはならない。
図１は、本発明の一実施の形態を示すシステム構成図である。
この実施形態のシステムでは、移動体通信装置１１０上で動作するユーザアプリケーション１２０と、ＳＱＬを解釈できるＤＢ部１５０と、ＤＢ部１５０とユーザアプリケーション１２０を結ぶためのテーブル操作用ＡＰＩ１４０と、テーブル操作用ＡＰＩ１４０の中に組み込んだ構造体計算部１４１、構造体への値格納部１４２、値解析部１４３、ＤＢ制御部１４４と、ＤＢのファイルシステム１６０とを移動体通信装置１１０内のメモリ（図示しない）に備えている。
例えば、移動体通信装置の代表例である携帯電話機へ始めてデータベースを搭載することを考える。従来の携帯電話機用プログラムの開発ではデータベースを用いていなかった。そのため、上位層アプリケーションではアドレス帳、スケジューラなどのデータアクセスには構造体を用いている。一方、ＤＢでアクセスするためには、テーブル名、カラム名、カラムの型、サイズなど、細かい情報が必要になる。ＤＢをアクセスするための汎用ミドル関数を作成する場合には、どのようなテーブルでもアクセスできるよう、テーブル名、カラム名などのＤＢ情報を保持し、その情報を元に取得した値を上位層に返却しなくてはならない。
図１では、移動体通信装置１１０が携帯電話機に相当し、ＤＢ制御部１４４以下がすべて新規作成となる。ユーザアプリケーション１２０はできるだけ既存のプログラムを流用できるようにしておきたい。
ユーザアプリケーション１２０は、テーブル操作を行うために、カード型構造体２３１を作成し、内部で保持する。また、出力結果を得るため、構造体型２３１の領域を確保する。
ユーザアプリケーション１２０は、テーブル操作を行うために、カード型構造体２３１を作成し、内部で保持する。また、出力結果を得るため、構造体型２３１の領域を確保する。
カード型構造体２３１では、以下のような情報を持つ。
（１）フィールド番号、（２）名前、（３）型種別（dword,worDByte,stringなど）。
それぞれの型種別ごとに格納サイズは決まる。dwordであれば４バイト、wordは２バイト、byteは１バイト。string型の場合はサイズが決まらないため、別途サイズを格納する領域が必要である。３２バイト分の文字列を格納するためには”string(32)”型と表記する。
構造体型１３２はＣ言語で使用される通常の構造体である。構造体のメンバは任意のものを受け取ることができる。構造体の詳細情報についてはカード型構造体１３１が持つ。
構造計算部１４１では、ユーザアプリケーション１２０から渡されたカード型構造体２３１から、実構造体の格納領域を計算する。
構造体への値格納部１４２では、ＤＢ制御部１４４によって、ＤＢのファイルシステム１６０からＤＢ部１５０を経由して取得されたデータを値解析部１４３で構造体格納用の値に変換し、構造体型１３２の領域に格納する。その際、構造体への格納は、名前参照を用いず直接アドレスを指定して値を格納する。指定する値は、構造計算部１４１で得られたメンバごとのオフセット値を、構造体の先頭アドレスに足したものを使用する。
（１）フィールド番号、（２）名前、（３）型種別（dword,worDByte,stringなど）。
それぞれの型種別ごとに格納サイズは決まる。dwordであれば４バイト、wordは２バイト、byteは１バイト。string型の場合はサイズが決まらないため、別途サイズを格納する領域が必要である。３２バイト分の文字列を格納するためには”string(32)”型と表記する。
構造体型１３２はＣ言語で使用される通常の構造体である。構造体のメンバは任意のものを受け取ることができる。構造体の詳細情報についてはカード型構造体１３１が持つ。
構造計算部１４１では、ユーザアプリケーション１２０から渡されたカード型構造体２３１から、実構造体の格納領域を計算する。
構造体への値格納部１４２では、ＤＢ制御部１４４によって、ＤＢのファイルシステム１６０からＤＢ部１５０を経由して取得されたデータを値解析部１４３で構造体格納用の値に変換し、構造体型１３２の領域に格納する。その際、構造体への格納は、名前参照を用いず直接アドレスを指定して値を格納する。指定する値は、構造計算部１４１で得られたメンバごとのオフセット値を、構造体の先頭アドレスに足したものを使用する。
値解析部１４３では、ＤＢのファイルシステム１６０から取得した値を構造体型１３２に格納できる形に変換する。
ＤＢ制御部１４４では、ＤＢ部１５０が受け取れる形式であるＳＱＬ文を作成し、直接にＤＢ部１５０を操作する。
ＤＢ部１５０はデータベースエンジンであり、ＳＱＬ文を受け付けて、ファイルシステム１６０に結果を記録する。
ＤＢ制御部１４４では、ＤＢ部１５０が受け取れる形式であるＳＱＬ文を作成し、直接にＤＢ部１５０を操作する。
ＤＢ部１５０はデータベースエンジンであり、ＳＱＬ文を受け付けて、ファイルシステム１６０に結果を記録する。
図２は、構造体メンバのオフセット計算で使用される各データの構成図である。
カード型構造体１３１は、構造体メンバごとに１枚のカードを持ち、その中に型情報をすべて格納しておく。そのカードを複数枚束ねると、テーブルを表現するための表形式となる。
表形式型２０１はデータ構造と値の両方を持つ。先頭行の項目名がデータ名を持ち、それぞれの型（word,dwordなど）が決まっている。次の行からは実際のデータが格納される。表形式はＤＢが使用する形式であり、実体の構造はユーザアプリケーション１２０から見えなくなっている。
構造体型１３２はユーザアプリケーション１２０が使用しやすいように構造体でアクセスできるようにしたデータ構造となる。ここにはデータの値のみが格納され、データの構造についてはヘッダファイル等に記載されることになる。構造体型１３２はカード型構造体１３１の値情報のみを取り出したものとみなすことができる。このように、カード型構造体１３１を経由することで、表形式型と構造体型との相互変換を可能にする。
カード型構造体１３１は、構造体メンバごとに１枚のカードを持ち、その中に型情報をすべて格納しておく。そのカードを複数枚束ねると、テーブルを表現するための表形式となる。
表形式型２０１はデータ構造と値の両方を持つ。先頭行の項目名がデータ名を持ち、それぞれの型（word,dwordなど）が決まっている。次の行からは実際のデータが格納される。表形式はＤＢが使用する形式であり、実体の構造はユーザアプリケーション１２０から見えなくなっている。
構造体型１３２はユーザアプリケーション１２０が使用しやすいように構造体でアクセスできるようにしたデータ構造となる。ここにはデータの値のみが格納され、データの構造についてはヘッダファイル等に記載されることになる。構造体型１３２はカード型構造体１３１の値情報のみを取り出したものとみなすことができる。このように、カード型構造体１３１を経由することで、表形式型と構造体型との相互変換を可能にする。
図３はテーブル操作用ＡＰＩ１４０が上位から呼出しを受けてから値を返却するまでの処理の流れを示したフローチャートである。
まず、テーブル操作用ＡＰＩ１４０が上位からの呼出しを受け、カード型構造体１３１の配列と構造体を受け取る（ステップ３０１）。
次に、構造計算部１４１が、引数で渡されたカード型構造体１３１の配列から構造体メンバのオフセットを計算する（ステップ３０２）。
次にＤＢのファイルシステム１６０から値を取得し、得た結果を構造体型１３２に格納可能な型に変換する（ステップ３０３）。
次に、取得した結果を引数で渡された構造体型１３２の領域に格納する（ステップ３０４）。その際、格納する領域はステップ３０２で計算されたオフセット値を使用する。
以上の手順により、カード型構造体１３１を受けて、構造体型１３２を返却するテーブル操作用ＡＰＩ機能を実現することができる。
まず、テーブル操作用ＡＰＩ１４０が上位からの呼出しを受け、カード型構造体１３１の配列と構造体を受け取る（ステップ３０１）。
次に、構造計算部１４１が、引数で渡されたカード型構造体１３１の配列から構造体メンバのオフセットを計算する（ステップ３０２）。
次にＤＢのファイルシステム１６０から値を取得し、得た結果を構造体型１３２に格納可能な型に変換する（ステップ３０３）。
次に、取得した結果を引数で渡された構造体型１３２の領域に格納する（ステップ３０４）。その際、格納する領域はステップ３０２で計算されたオフセット値を使用する。
以上の手順により、カード型構造体１３１を受けて、構造体型１３２を返却するテーブル操作用ＡＰＩ機能を実現することができる。
図４は、図３のステップ３０２におけるオフセットを計算する処理の流れを示すフローチャートである。
構造体のメンバを配置する規則は規定されていないが、一般的なコンパイラでは以下のような規則がある。
（１）dword型のデータは４バイト境界に乗せる。
（２）word型のデータは２バイト境界に乗せる。
（３）byte型データは規定しない。
（４）string型データも規定しない。なおここで、string型はＣ言語のchar型配列で格納されるものと想定している。
バイト境界に乗らないデータがあった場合は、バイト境界に合わせるため、メンバ格納領域の直前に埋め草を作る。例えば、byte型の後にword型が来た場合、byte型の後に１バイトの埋め草が挿入される。
構造体のメンバを配置する規則は規定されていないが、一般的なコンパイラでは以下のような規則がある。
（１）dword型のデータは４バイト境界に乗せる。
（２）word型のデータは２バイト境界に乗せる。
（３）byte型データは規定しない。
（４）string型データも規定しない。なおここで、string型はＣ言語のchar型配列で格納されるものと想定している。
バイト境界に乗らないデータがあった場合は、バイト境界に合わせるため、メンバ格納領域の直前に埋め草を作る。例えば、byte型の後にword型が来た場合、byte型の後に１バイトの埋め草が挿入される。
この動作を前提として、オフセット値を計算する方法を以下に説明する。
まず、初期オフセットを“０”とする（ステップ４０１）。
次に、カードを１枚参照し、型を調べる（ステップ４０２）。そして、現在のオフセットが、型のバイト境界に入っているかどうかを調べる（ステップ４０３）。例えば、当該型がwordであったとき、オフセットが“２”で割り切れるかどうかを調べる。バイト境界が正しい場合は、現在のオフセットに値を格納する。正しくない場合は、バイト境界が正しくなるまで、オフセットを“＋１”していく（ステップ４０４）。
次に、型のサイズ分、オフセットを増加する（ステップ４０５）。例えば、ｗｏｒｄであれば“＋２”、ｄｗｏｒｄであれば“＋４”増加する。
カード型構造体の配列データがなくなるまでステップ４０２から繰り返す（ステップ４０６）。
まず、初期オフセットを“０”とする（ステップ４０１）。
次に、カードを１枚参照し、型を調べる（ステップ４０２）。そして、現在のオフセットが、型のバイト境界に入っているかどうかを調べる（ステップ４０３）。例えば、当該型がwordであったとき、オフセットが“２”で割り切れるかどうかを調べる。バイト境界が正しい場合は、現在のオフセットに値を格納する。正しくない場合は、バイト境界が正しくなるまで、オフセットを“＋１”していく（ステップ４０４）。
次に、型のサイズ分、オフセットを増加する（ステップ４０５）。例えば、ｗｏｒｄであれば“＋２”、ｄｗｏｒｄであれば“＋４”増加する。
カード型構造体の配列データがなくなるまでステップ４０２から繰り返す（ステップ４０６）。
図５は上記手順を元に、実例を示したものである。
カード型構造体データ５１０を用意する。オフセット計算５２０でメンバを１つずつ参照する。ステップ５２１では、byte型であるため、オフセットは“０”となり、次オフセットを“１”にする。
ステップ５２２では、オフセット１のところに、word型が出現したため、埋め草を挿入する。deptcdのオフセットは“２”となり、次オフセットは“４”となる。
ステップ５２３では、オフセット４のところに、dword型が出現したため、workのオフセットは“４”となる。
以上の手順により計算結果５３０が決定される。
カード型構造体データ５１０を用意する。オフセット計算５２０でメンバを１つずつ参照する。ステップ５２１では、byte型であるため、オフセットは“０”となり、次オフセットを“１”にする。
ステップ５２２では、オフセット１のところに、word型が出現したため、埋め草を挿入する。deptcdのオフセットは“２”となり、次オフセットは“４”となる。
ステップ５２３では、オフセット４のところに、dword型が出現したため、workのオフセットは“４”となる。
以上の手順により計算結果５３０が決定される。
なお、本発明は上述した機能に限定されるものではない。例えば、オフセット計算の計算規則を変更することで、埋め草の入れ方を使用するコンパイラに合わせることができる。また、入れ方を複数通り準備しておくことにより、オフセット計算規則が定まっていない環境での計算規則を推測することができる。
１１０…移動体通信装置、１２０…ユーザアプリケーション、１３１…カード型構造体、１３２…構造体型、１４０…テーブル操作ＡＰＩ、１４１…構造計算部、１４２…構造体への値格納部、１４３…値解析部、１４４…ＤＢ制御部、１５０…ＤＢ部、１６０…ＤＢのファイルシステム、３０１…テーブル、５１０…カード型データ、５２０…オフセット計算処理、５３０…計算結果６０１…ユーザアプリケーションプログラム、６０２…ＤＡＯクラス、６０３…テーブル型データ、６０４…ＤＢ依存Interface。
Claims (1)
- ユーザアプリケーションプログラムから構造体のメンバ毎に１枚のカード型構造体により構成される複数のカード型構造体を受取り、その受け取った各カード型構造体に格納された型情報によって各メンバの値の格納サイズを計算し、計算結果のメンバ値を格納する構造体の格納領域を作成する第１の手段と、前記複数のカード型構造体のそれぞれで指定されたメンバ値を下位層のデータベース等から取得する第２の手段と、取得したメンバ値を前記第１の手段で作成した格納領域の構造体に格納し、前記ユーザアプリケーションプログラムに返す第３の手段としてコンピュータを機能させるステップを備えることを特徴とするテーブル操作用インタフェースプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007054118A JP2008217439A (ja) | 2007-03-05 | 2007-03-05 | テーブル操作用インタフェースプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007054118A JP2008217439A (ja) | 2007-03-05 | 2007-03-05 | テーブル操作用インタフェースプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2008217439A true JP2008217439A (ja) | 2008-09-18 |
Family
ID=39837400
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007054118A Pending JP2008217439A (ja) | 2007-03-05 | 2007-03-05 | テーブル操作用インタフェースプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2008217439A (ja) |
-
2007
- 2007-03-05 JP JP2007054118A patent/JP2008217439A/ja active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111367976B (zh) | 基于java反射机制的excel文件数据的导出方法及装置 | |
| CN104731589A (zh) | 用户界面的自动生成方法及自动生成装置 | |
| CN108304676B (zh) | 装配体三维模型自动重建方法、终端设备及存储介质 | |
| CN106796525B (zh) | 按需加载动态脚本语言代码以减少内存使用 | |
| CN112256321A (zh) | 静态库打包方法、装置、计算机设备和存储介质 | |
| CN108776587B (zh) | 数据获取方法、装置、计算机设备以及存储介质 | |
| US11392765B2 (en) | Interpreting HL7 segment hierarchy dynamically | |
| CN112068911B (zh) | 电子表单的生成方法、装置、系统、设备以及介质 | |
| CN111274263A (zh) | 可视化数据库变更语句生成方法、装置及存储介质 | |
| CN112764802A (zh) | 一种业务逻辑定制方法、装置、电子设备和存储介质 | |
| KR20040097937A (ko) | 오브젝트 기반의 파이프라인을 채용한 시스템 및 방법 | |
| EP3457274A1 (en) | System and method for creating domain specific language | |
| CN110362630B (zh) | 数据管理方法、装置、设备与计算机可读存储介质 | |
| US8433729B2 (en) | Method and system for automatically generating a communication interface | |
| CN111930363B (zh) | 区块接口代码生成方法、及装置 | |
| CN116521181B (zh) | 基于游戏系统的脚本数据处理方法、装置、设备及介质 | |
| CN108664505B (zh) | 一种数据库表结构的导出方法及装置 | |
| CN112306473A (zh) | 一种程序接口传参方法、系统及相关设备 | |
| CN116028062A (zh) | 目标代码的生成方法、npu指令的显示方法及装置 | |
| CN110795920A (zh) | 一种文档生成方法及设备 | |
| CN114020278B (zh) | 数据处理方法、装置、设备及存储介质 | |
| KR101828466B1 (ko) | 파일시스템을 기반으로 하는 저장장치에서 객체기반 스토리지 인터페이스를 제공하는 방법 및 장치 | |
| US10310871B2 (en) | Non-transitory computer-readable recording medium storing control program, control device and control method | |
| CN107092601B (zh) | 资源文件构建方法、资源文件应用方法及装置 | |
| CN111581578B (zh) | 接口请求处理方法和装置 |