Elixir 1.7 - Application

अनुप्रयोग व्यवहार




elixir

अनुप्रयोग व्यवहार

एप्लिकेशन के साथ काम करने और एप्लिकेशन कॉलबैक को परिभाषित करने के लिए एक मॉड्यूल।

अनुप्रयोग Erlang / OTP में सॉफ़्टवेयर को पैकेज करने का मुहावरेदार तरीका है। विचार प्राप्त करने के लिए, वे अन्य प्रोग्रामिंग भाषाओं में "लाइब्रेरी" अवधारणा के समान हैं, लेकिन कुछ अतिरिक्त विशेषताओं के साथ।

एक आवेदन एक मानकीकृत निर्देशिका संरचना, विन्यास और जीवनचक्र के साथ कुछ विशिष्ट कार्यक्षमता को लागू करने वाला एक घटक है। एप्लिकेशन लोड किए गए हैं , शुरू किए गए हैं, और बंद कर दिए गए हैं

एप्लिकेशन संसाधन फ़ाइल

एप्लिकेशन उनकी संसाधन फ़ाइल में निर्दिष्ट किए जाते हैं, जो कि APP.app नामक एक फ़ाइल है, जहां APP एप्लिकेशन नाम है। उदाहरण के लिए, OTP आवेदन ex_unit के एप्लिकेशन संसाधन फ़ाइल को ex_unit कहा जाता है।

आपको किसी एप्लिकेशन की संसाधन फ़ाइल उसकी ebin निर्देशिका में मिल जाएगी, यह मिक्स द्वारा स्वचालित रूप से जेनरेट होता है। इसकी कुछ कुंजियाँ project/0 द्वारा दी गई कीवर्ड सूचियों से ली गई हैं और mix.exs में परिभाषित application/0 फ़ंक्शंस, और अन्य मिक्स द्वारा ही जेनरेट किए गए हैं।

आप Mix.Tasks.Compile.App के प्रलेखन में एप्लिकेशन संसाधन फ़ाइलों की पीढ़ी के बारे में अधिक जानकारी प्राप्त कर सकते हैं, साथ ही साथ mix help compile.app चलाकर भी उपलब्ध mix help compile.app

अनुप्रयोग वातावरण

अनुप्रयोग संसाधन फ़ाइल के प्रमुख env में tuples की एक सूची होती है, जो परमाणुओं को मैप करती है, और इसकी सामग्री को अनुप्रयोग वातावरण के रूप में जाना जाता है । ध्यान दें कि यह वातावरण ऑपरेटिंग सिस्टम वातावरण से संबंधित नहीं है।

डिफ़ॉल्ट रूप से, अनुप्रयोग का वातावरण एक रिक्त सूची है। मिक्स प्रोजेक्ट में आप उस कुंजी को application/0 में सेट कर सकते हैं:

def application do
  [env: [redis_host: "localhost"]]
end

और जेनरेट की गई एप्लिकेशन रिसोर्स फ़ाइल इसमें शामिल करने जा रही है।

एप्लिकेशन लोड करने के बाद पर्यावरण उपलब्ध है, जो बाद में बताई गई एक प्रक्रिया है:

Application.load(:APP_NAME)
#=> :ok

Application.get_env(:APP_NAME, :redis_host)
#=> "localhost"

मिक्स प्रोजेक्ट्स में, एप्लिकेशन का वातावरण और इसकी निर्भरताएँ config/config.exs फ़ाइल के माध्यम से ओवरराइड की जा सकती हैं। यदि आप मिक्स के साथ एप्लिकेशन शुरू करते हैं, तो वह कॉन्फ़िगरेशन संकलित समय पर, और रनटाइम पर भी उपलब्ध है, लेकिन ध्यान रखें कि यह उत्पन्न एप्लिकेशन संसाधन फ़ाइल में शामिल नहीं है, और यदि आप मिक्स के बिना एप्लिकेशन शुरू करते हैं तो यह उपलब्ध नहीं है।

उदाहरण के लिए, आपके एप्लिकेशन का उपयोग करने वाला कोई व्यक्ति इसके ओवरराइड कर सकता है :redis_host पर्यावरण चर इस प्रकार है:

config :APP_NAME, redis_host: "redis.local"

फ़ंक्शन put_env/3 एप्लिकेशन वातावरण के गतिशील कॉन्फ़िगरेशन की अनुमति देता है, लेकिन अंगूठे के नियम के रूप में प्रत्येक एप्लिकेशन अपने स्वयं के वातावरण के लिए जिम्मेदार है। कृपया इस मॉड्यूल में अन्य अनुप्रयोगों के वातावरण को सीधे एक्सेस या संशोधित करने के लिए फ़ंक्शन का उपयोग न करें।

एप्लिकेशन वातावरण को erl के -config विकल्प और साथ ही कमांड-लाइन झंडे के माध्यम से ओवरराइड किया जा सकता है, जैसा कि हम नीचे देखने जा रहे हैं।

अनुप्रयोग कॉलबैक मॉड्यूल

एप्लिकेशन संसाधन फ़ाइल की mod कुंजी एक एप्लिकेशन कॉलबैक मॉड्यूल को कॉन्फ़िगर करती है और तर्क शुरू करती है:

def application do
  [mod: {MyApp, []}]
end

यह कुंजी वैकल्पिक है, केवल उन अनुप्रयोगों के लिए आवश्यक है जो एक पर्यवेक्षण वृक्ष शुरू करते हैं।

दिए गए MyApp मॉड्यूल :mod को Application व्यवहार को लागू करने की आवश्यकता है। यह उस मॉड्यूल में use Application डालकर किया जा सकता है और उदाहरण के लिए start/2 कॉलबैक लागू किया जा सकता है:

defmodule MyApp do
  use Application

  def start(_type, _args) do
    children = []
    Supervisor.start_link(children, strategy: :one_for_one)
  end
end

start/2 कॉलबैक को एक पर्यवेक्षक को स्पॉन और लिंक करना होगा और {:ok, pid} या {:ok, pid, state} , जहां pid पर्यवेक्षक का PID है, और state एक वैकल्पिक अनुप्रयोग स्थिति है। args tuple का दूसरा तत्व है :mod विकल्प।

start/2 लिए पास किया गया type तर्क आमतौर पर :normal वितरित वितरण में :normal जब तक कि आवेदन अधिग्रहण और विफलता को कॉन्फ़िगर नहीं किया जाता है। वितरित अनुप्रयोग इस दस्तावेज़ के दायरे से परे हैं।

जब कोई एप्लिकेशन बंद हो रहा है, तो इसके stop/1 कॉलबैक को रनटाइम द्वारा पर्यवेक्षण के पेड़ को stop/1 बाद कहा जाता है। यह कॉलबैक एप्लिकेशन को किसी भी अंतिम सफाई करने की अनुमति देता है। तर्क वह स्थिति है जो start/2 लौटती है, यदि उसने किया, या [] अन्यथा। stop/1 रिटर्न मान को अनदेखा किया जाता है।

Application का उपयोग करके, मॉड्यूल को stop/1 का एक डिफ़ॉल्ट कार्यान्वयन मिलता है जो इसके तर्क और रिटर्न को अनदेखा करता है :ok , लेकिन इसे ओवरराइड किया जा सकता है।

एप्लिकेशन कॉलबैक मॉड्यूल वैकल्पिक कॉलबैक prep_stop/1 को भी लागू कर सकता है। यदि वर्तमान में, पर्यवेक्षण वृक्ष समाप्त होने से पहले prep_stop/1 को लागू किया जाता है। इसका तर्क है कि राज्य start/2 , अगर यह किया, या [] अन्यथा, और इसके वापसी मूल्य को stop/1 द्वारा वापस आ गया है।

अनुप्रयोग जीवनचक्र

लोड हो रहा है अनुप्रयोगों

एप्लिकेशन लोड किए गए हैं , जिसका अर्थ है कि रनटाइम उनकी संसाधन फ़ाइलों को ढूंढता है और संसाधित करता है:

Application.load(:ex_unit)
#=> :ok

यदि किसी एप्लिकेशन में एप्लिकेशन शामिल हैं, तो वे भी लोड किए गए हैं। और प्रक्रिया फिर से आती है अगर वे बदले में अनुप्रयोगों को शामिल करते हैं। मिक्स अम्ब्रेला प्रोजेक्ट्स में शामिल अनुप्रयोगों के लिए असंबंधित अनुप्रयोग हैं, वे एक एर्लांग / ओटीपी अवधारणा हैं जो समन्वित शुरुआत के साथ करना है।

जब कोई एप्लिकेशन लोड की जाती है, तो उसकी संसाधन फ़ाइल में निर्दिष्ट वातावरण को -config विकल्प के माध्यम से -config दी गई कॉन्फिग फाइलों से किसी भी ओवरराइड में मिला दिया जाता है। यह हाइलाइट करने के लायक है जो इस तरह से sys.config रिलीज़ करता है। परिणामी वातावरण अभी भी फिर से overridden के माध्यम से erl लिए पारित विशिष्ट -Application झंडे के माध्यम से -Application किया जा सकता है।

किसी एप्लिकेशन को लोड करना उसके मॉड्यूल को लोड नहीं करता है

व्यवहार में, आप शायद ही कभी अनुप्रयोगों को हाथ से लोड करते हैं क्योंकि यह शुरू की प्रक्रिया का हिस्सा है, आगे बताया गया है।

आवेदन शुरू करना

आवेदन भी शुरू कर रहे हैं:

Application.start(:ex_unit)
#=> :ok

एक बार आपका आवेदन संकलित हो जाने के बाद, आपका सिस्टम चलाना आपके वर्तमान एप्लिकेशन और उसकी निर्भरता को शुरू करने का विषय है। अन्य भाषाओं से भिन्न, एलिक्सिर में एक main प्रक्रिया नहीं है जो आपके सिस्टम को शुरू करने के लिए जिम्मेदार है। इसके बजाय, आप एक या एक से अधिक एप्लिकेशन शुरू करते हैं, जिनमें से प्रत्येक अपने स्वयं के प्रारंभ और समाप्ति तर्क के साथ होता है।

जब कोई एप्लिकेशन शुरू किया जाता है, तो रनटाइम इसे लोड करता है यदि इसे अभी तक लोड नहीं किया गया है (ऊपर वर्णित तकनीकी अर्थ में)। उसके बाद, यह जाँचता है कि संसाधन फ़ाइल के applications कुंजी में सूचीबद्ध निर्भरताएँ पहले ही शुरू हो चुकी हैं। कम से कम एक निर्भरता शुरू नहीं करना एक त्रुटि स्थिति है, लेकिन जब आप mix run साथ एक एप्लिकेशन शुरू करते हैं, तो मिक्स आपके लिए सभी निर्भरताएं शुरू करने का ख्याल रखता है, इसलिए अभ्यास में आपको इसके बारे में चिंता करने की आवश्यकता नहीं है जब तक कि आप आवेदन शुरू नहीं कर रहे हैं। मैन्युअल रूप से इस मॉड्यूल द्वारा प्रदान की गई एपीआई के साथ।

यदि एप्लिकेशन में कॉलबैक मॉड्यूल कॉन्फ़िगर नहीं है, तो प्रारंभ इस बिंदु पर किया जाता है। अन्यथा, इसकी start/2 कॉलबैक यदि आह्वान किया जाता है। इस फ़ंक्शन द्वारा लौटाए गए शीर्ष-स्तरीय पर्यवेक्षक की PID को बाद के उपयोग के लिए रनटाइम द्वारा संग्रहीत किया जाता है, और लौटाया गया एप्लिकेशन स्टेट भी सहेजा जाता है, यदि कोई हो।

आवेदन रोकना

शुरू किए गए आवेदन, आखिरकार, रुके हैं :

Application.stop(:ex_unit)
#=> :ok

कॉलबैक मॉड्यूल के बिना किसी एप्लिकेशन को रोकना परिभाषित किया गया है, लेकिन कुछ सिस्टम ट्रेसिंग को छोड़कर, यह एक नो-ऑप का अभ्यास करता है।

कॉलबैक मॉड्यूल के साथ एप्लिकेशन को रोकने के तीन चरण हैं:

  1. यदि मौजूद है, तो वैकल्पिक कॉलबैक prep_stop/1 लागू करें।
  2. शीर्ष-स्तरीय पर्यवेक्षक को समाप्त करें।
  3. आवश्यक कॉलबैक stop/1

कॉलबैक के लिए दिए गए तर्क राज्य से संबंधित हैं जो वैकल्पिक रूप से start/2 द्वारा लौटाए गए हैं, और ऊपर कॉलबैक मॉड्यूल के बारे में अनुभाग में प्रलेखित हैं।

यह उजागर करना महत्वपूर्ण है कि चरण 2 एक अवरुद्ध है। एक पर्यवेक्षक की समाप्ति बच्चों की समाप्ति की एक पुनरावर्ती श्रृंखला को ट्रिगर करती है, इसलिए सभी वंश प्रक्रियाओं को व्यवस्थित रूप से बंद कर देती है। पूरे पर्यवेक्षण वृक्ष की समाप्ति के बाद ही stop/1 कॉलबैक लागू किया जाता है।

सिस्टम को लाइव करके साफ किया जा सकता है। System.stop/1 कॉल करके। यह उनके द्वारा शुरू किए गए विपरीत क्रम में हर एप्लिकेशन को बंद कर देगा।

Erlang / OTP 19.1 से, ऑपरेटिंग सिस्टम से एक SIGTERM स्वचालित रूप से System.stop/0 अनुवाद करेगा। Erlang / OTP 20 उपयोगकर्ता को OS संकेतों पर अधिक स्पष्ट नियंत्रण देता है :os.set_signal/2 फ़ंक्शन।

टूलींग

मिक्स बिल्ड टूल का उपयोग आपके एप्लिकेशन को शुरू करने के लिए भी किया जा सकता है। उदाहरण के लिए, mix test स्वचालित रूप से आपके आवेदन पर निर्भर करता है और आपके परीक्षण के चलने से पहले ही आपका आवेदन शुरू हो जाता है। mix run --no-halt आपके वर्तमान प्रोजेक्ट को बूट करता है और इसका उपयोग लंबे समय तक चलने वाले सिस्टम को शुरू करने के लिए किया जा सकता है। mix help run देखें।

डेवलपर्स Distillery जैसे उपकरणों का भी उपयोग कर सकते हैं जो रिलीज का निर्माण करते हैं । रिलीज़ आपके सभी स्रोत कोड के साथ-साथ Erlang VM को एक ही निर्देशिका में पैकेज करने में सक्षम हैं। विज्ञप्ति आपको इस बात पर भी स्पष्ट नियंत्रण देती है कि प्रत्येक आवेदन किस प्रकार और किस क्रम में शुरू किया गया है। वे सिस्टम शुरू करने और रोकने, डिबगिंग, लॉगिंग के साथ-साथ सिस्टम मॉनिटरिंग के लिए एक अधिक सुव्यवस्थित तंत्र भी प्रदान करते हैं।

अंत में, एलिक्जिर एस्क्रीप्ट्स और आर्काइव्स जैसे उपकरण प्रदान करता है, जो आपके आवेदन की पैकेजिंग के लिए विभिन्न तंत्र हैं। उन का उपयोग आमतौर पर तब किया जाता है जब उपकरण डेवलपर्स के बीच साझा किए जाने चाहिए और तैनाती विकल्प के रूप में नहीं। mix help archive.build देखें। अधिक विवरण के लिए mix help escript.build

अग्रिम जानकारी

अनुप्रयोगों के बारे में अधिक जानकारी के लिए कृपया अर्लंग मॉड्यूल, और ओटीपी डिज़ाइन सिद्धांत उपयोगकर्ता गाइड के Applications अनुभाग के प्रलेखन की जाँच करें।

सारांश

प्रकार

app()
key()
restart_type()
start_type()
state()
value()

कार्य

app_dir(app)

एप्लिकेशन के लिए निर्देशिका प्राप्त करता है

app_dir (ऐप, पथ)

दिए गए पथ को app_dir(app) अंदर app_dir(app)

delete_env (ऐप, कुंजी, opts \\ [])

दिए गए app वातावरण से key हटाता है

सुनिश्चित करें कि_अनुरक्षित (एप्लिकेशन, टाइप करें \\: अस्थायी)

दिए गए app और उसके अनुप्रयोगों को सुनिश्चित करता है

सुनिश्चित करें_स्टार्ट (ऐप, टाइप करें \\: अस्थायी)

दिए गए app को शुरू करना सुनिश्चित करता है

fetch_env! (ऐप, कुंजी)

app के वातावरण में key लिए मान लौटाता है

fetch_env (ऐप, कुंजी)

एक टपल में app के वातावरण में key लिए मान देता है

format_error(reason)

start/2 , ensure_started/2 , stop/1 , load/1 और unload/1 द्वारा लौटाए गए त्रुटि का कारण ensure_started/2 , एक स्ट्रिंग लौटाता है

get_all_env(app)

app लिए सभी कुंजी-मूल्य जोड़े देता है

get_application(module)

दिए गए मॉड्यूल के लिए आवेदन प्राप्त करता है

get_env (ऐप, कुंजी, डिफ़ॉल्ट \\ nil)

app के वातावरण में key लिए मान लौटाता है

load/1

दिए गए app लोड करता है

loaded_applications()

उन अनुप्रयोगों के बारे में जानकारी के साथ एक सूची लौटाता है जिन्हें लोड किया गया है

put_env (ऐप, कुंजी, मान, opts \\ [])

दिए गए app लिए key में value डालता है

spec(app)

app लिए युक्ति लौटाता है

युक्ति (ऐप, कुंजी)

app के विनिर्देशन में key लिए मान लौटाता है

start/2

दिए गए app शुरू करता है

start_applications (टाइमआउट \\ 5000)

वर्तमान में चल रहे अनुप्रयोगों के बारे में जानकारी के साथ एक सूची लौटाता है

stop/1

दिए गए app बंद कर देता है

unload/1

दिए गए app लोड करता है

कॉलबैक

prep_stop/1

आवेदन रोकने से पहले फोन किया

start/2

आवेदन शुरू होने पर कॉल किया जाता है

start_phase (चरण, start_type, phase_args)

तुल्यकालिक चरणों में एक आवेदन शुरू करें

stop/1

एक आवेदन को रोकने के बाद कॉल किया गया

प्रकार

एप्लिकेशन ()

app() :: atom()

कुंजी ()

key() :: atom()

restart_type ()

restart_type() :: :permanent | :transient | :temporary

start_type ()

start_type() :: :normal | {:takeover, node()} | {:failover, node()}

राज्य ()

state() :: term()

मूल्य ()

value() :: term()

कार्य

app_dir (ऐप्लिकेशन)

app_dir(app()) :: String.t()

एप्लिकेशन के लिए निर्देशिका प्राप्त करता है।

यह जानकारी कोड पथ के आधार पर दी गई है। यहाँ एक उदाहरण है:

File.mkdir_p!("foo/ebin")
Code.prepend_path("foo/ebin")
Application.app_dir(:foo)
#=> "foo"

भले ही निर्देशिका खाली है और कोई .app फ़ाइल नहीं है, इसे "foo / ebin" नाम के आधार पर एप्लिकेशन निर्देशिका माना जाता है। नाम में डैश हो सकता है - जिसे ऐप संस्करण माना जाता है और इसे लुकअप उद्देश्यों के लिए हटा दिया गया है:

File.mkdir_p!("bar-123/ebin")
Code.prepend_path("bar-123/ebin")
Application.app_dir(:bar)
#=> "bar-123"

कोड रास्तों के बारे में अधिक जानकारी के लिए, एलिक्सिर में Code मॉड्यूल की जांच करें और एरलांग का :code मॉड्यूल भी

app_dir (ऐप, पथ)

app_dir(app(), String.t() | [String.t()]) :: String.t()

दिए गए पथ को app_dir(app) अंदर app_dir(app)

यदि path एक स्ट्रिंग है, तो इसका उपयोग app_dir(app) अंदर पथ के रूप में किया जाएगा। यदि path स्ट्रिंग्स की एक सूची है, तो यह शामिल हो जाएगा ( Path.join/1 देखें) और परिणाम का उपयोग app_dir(app) अंदर पथ के रूप में किया जाएगा।

उदाहरण

File.mkdir_p!("foo/ebin")
Code.prepend_path("foo/ebin")

Application.app_dir(:foo, "my_path")
#=> "foo/my_path"

Application.app_dir(:foo, ["my", "nested", "path"])
#=> "foo/my/nested/path"

delete_env (ऐप, कुंजी, opts \\ [])

delete_env(app(), key(), timeout: timeout(), persistent: boolean()) :: :ok

दिए गए app वातावरण से key हटाता है।

विकल्पों के विवरण के लिए put_env/4 देखें।

सुनिश्चित करें कि_अनुरक्षित (एप्लिकेशन, टाइप करें \\: अस्थायी)

ensure_all_started(app(), restart_type()) ::
  {:ok, [app()]} | {:error, {app(), term()}}

दिए गए app और उसके अनुप्रयोगों को सुनिश्चित करता है।

start/2 रूप में भी लेकिन यह भी सूचीबद्ध अनुप्रयोगों के तहत शुरू होता है :applications में .app फ़ाइल के मामले में वे पहले शुरू नहीं थे।

सुनिश्चित करें_स्टार्ट (ऐप, टाइप करें \\: अस्थायी)

ensure_started(app(), restart_type()) :: :ok | {:error, term()}

दिए गए app को शुरू करना सुनिश्चित करता है।

start/2 रूप में भी लेकिन रिटर्न :ok अगर आवेदन पहले से ही शुरू किया गया था। यह स्क्रिप्ट और परीक्षण सेटअप में उपयोगी है, जहां परीक्षण अनुप्रयोगों को स्पष्ट रूप से शुरू करने की आवश्यकता है:

:ok = Application.ensure_started(:my_test_dep)

fetch_env! (ऐप, कुंजी)

fetch_env!(app(), key()) :: value() | no_return()

app के वातावरण में key लिए मान लौटाता है।

यदि कॉन्फ़िगरेशन पैरामीटर मौजूद नहीं है, तो ArgumentError उठाता है।

fetch_env (ऐप, कुंजी)

fetch_env(app(), key()) :: {:ok, value()} | :error

एक टपल में app के वातावरण में key लिए मान देता है।

यदि कॉन्फ़िगरेशन पैरामीटर मौजूद नहीं है, तो फ़ंक्शन वापस आता है :error

format_error (कारण)

format_error(any()) :: String.t()

start/2 , ensure_started/2 , stop/1 , load/1 और unload/1 द्वारा लौटाए गए त्रुटि कारण को एक प्रारूप देता है।

get_all_env (ऐप्लिकेशन)

get_all_env(app()) :: [{key(), value()}]

app लिए सभी कुंजी-मूल्य जोड़े देता है।

get_application (मॉड्यूल)

get_application(atom()) :: atom() | nil

दिए गए मॉड्यूल के लिए आवेदन प्राप्त करता है।

आवेदन सभी लोड किए गए अनुप्रयोगों की कल्पना का विश्लेषण करके स्थित है। मॉड्यूल किसी भी आवेदन कल्पना में सूचीबद्ध नहीं है, तो nil लौटाता है।

get_env (ऐप, कुंजी, डिफ़ॉल्ट \\ nil)

get_env(app(), key(), value()) :: value()

app के वातावरण में key लिए मान लौटाता है।

यदि कॉन्फ़िगरेशन पैरामीटर मौजूद नहीं है, तो फ़ंक्शन default मान लौटाता है।

उदाहरण

get_env/3 का उपयोग आमतौर पर आपके OTP अनुप्रयोगों के कॉन्फ़िगरेशन को पढ़ने के लिए किया जाता है। चूंकि मिक्स कॉन्फ़िगरेशन आमतौर पर अनुप्रयोगों को कॉन्फ़िगर करने के लिए उपयोग किया जाता है, इसलिए हम इसे दृष्टांत के रूप में उपयोग करेंगे।

नए एप्लिकेशन पर विचार करें :my_app :my_app में एक डेटाबेस इंजन होता है जो डेटाबेस के एक पूल का समर्थन करता है। डेटाबेस इंजन को उन डेटाबेसों में से प्रत्येक के लिए कॉन्फ़िगरेशन को जानना होगा, और उस कॉन्फ़िगरेशन को कुंजी-मूल्य जोड़े द्वारा पर्यावरण :my_app में आपूर्ति की जाती है।

config :my_app, Databases.RepoOne,
  # A database configuration
  ip: "localhost"
  port: 5433

config :my_app, Databases.RepoTwo,
  # Another database configuration (for the same OTP app)
  ip: "localhost"
  port: 20717

config :my_app, my_app_databases: [Databases.RepoOne, Databases.RepoTwo]

हमारे डेटाबेस इंजन का उपयोग किया जाता है :my_app को यह जानने की आवश्यकता है कि डेटाबेस क्या मौजूद है, और डेटाबेस कॉन्फ़िगरेशन क्या हैं। डेटाबेस इंजन डेटाबेस की सूची (मॉड्यूल नामों द्वारा निर्दिष्ट get_env(:my_app, :my_app_databases) को पुनः प्राप्त करने के लिए get_env(:my_app, :my_app_databases) डेटाबेस get_env(:my_app, :my_app_databases) को कॉल कर सकता है। हमारा डेटाबेस इंजन फिर सूची में प्रत्येक रिपॉजिटरी को पार कर सकता है और फिर get_env(:my_app, Databases.RepoOne) कॉल कर get_env(:my_app, Databases.RepoOne) और प्रत्येक के कॉन्फ़िगरेशन को पुनः प्राप्त करने के लिए आगे।

महत्वपूर्ण: यदि आप अन्य डेवलपर्स द्वारा उपयोग किए जाने के लिए एक पुस्तकालय लिख रहे हैं, तो आमतौर पर आवेदन के वातावरण से बचने के लिए सिफारिश की जाती है, क्योंकि अनुप्रयोग वातावरण प्रभावी रूप से एक वैश्विक भंडारण है। अधिक जानकारी के लिए, हमारे पुस्तकालय दिशानिर्देश पढ़ें।

लोड (एप्लिकेशन)

load(app()) :: :ok | {:error, term()}

दिए गए app लोड करता है।

लोड किए जाने के लिए, लोड पथ में एक .app फ़ाइल होनी चाहिए। सभी :included_applications गए_प्लिकेशंस भी लोड :included_applications जाएंगे।

लोड हो रहा है एप्लिकेशन इसे शुरू नहीं करता है और न ही इसके मॉड्यूल लोड करता है, लेकिन यह इसके पर्यावरण को लोड करता है।

loaded_applications ()

loaded_applications() :: [
  {app(), description :: charlist(), vsn :: charlist()}
]

उन अनुप्रयोगों के बारे में जानकारी के साथ एक सूची लौटाता है जिन्हें लोड किया गया है।

put_env (ऐप, कुंजी, मान, opts \\ [])

put_env(app(), key(), value(), timeout: timeout(), persistent: boolean()) ::
  :ok

दिए गए app लिए key में value डालता है।

विकल्प

  • :timeout - परिवर्तन के लिए समय सीमा ( 5_000 मिलीसेकंड तक चूक)
  • :persistent - आवेदन लोड और पुनः लोड पर दिए गए मूल्य को :persistent रखता है

यदि put_env/4 को एप्लिकेशन लोड होने से पहले कॉल किया जाता है, तो .app फ़ाइल में निर्दिष्ट एप्लिकेशन पर्यावरण मान पहले से सेट किए गए लोगों को ओवरराइड करेगा।

लगातार विकल्प को true सेट किया जा सकता true जब लोड पर एप्लिकेशन संसाधन फ़ाइल में परिभाषित किए गए इस फ़ंक्शन के साथ निर्धारित मापदंडों की गारंटी देने की आवश्यकता होती है। इसका अर्थ है कि एप्लिकेशन लोड होने के बाद और एप्लिकेशन रीलोड होने के बाद भी लगातार मान चिपक जाएगा।

कल्पना (ऐप्लिकेशन)

spec(app()) :: [{key(), value()}] | nil

app लिए युक्ति लौटाता है।

निम्नलिखित कुंजियाँ दी गई हैं:

  • :description
  • :id
  • :vsn
  • :modules
  • :maxP
  • :maxT
  • :registered
  • :included_applications
  • :applications
  • :mod
  • :start_phases

ध्यान दें कि वातावरण वापस नहीं है क्योंकि इसे fetch_env/2 माध्यम से एक्सेस किया जा सकता है। यदि एप्लिकेशन लोड नहीं है, तो nil लौटाता है।

युक्ति (ऐप, कुंजी)

spec(app(), key()) :: value() | nil

app के विनिर्देशन में key लिए मान लौटाता है।

समर्थित कुंजियों के लिए spec(app) देखें। यदि दिए गए विनिर्देश पैरामीटर मौजूद नहीं हैं, तो यह फ़ंक्शन बढ़ाएगा। यदि एप्लिकेशन लोड नहीं है, तो nil लौटाता है।

प्रारंभ (एप्लिकेशन, टाइप करें \\: अस्थायी)

start(app(), restart_type()) :: :ok | {:error, term()}

दिए गए app शुरू करता है।

यदि app लोड नहीं है, तो एप्लिकेशन को पहले load/1 का उपयोग करके load/1 किया जाएगा। कोई भी शामिल अनुप्रयोग, जिसमें परिभाषित किया गया है :included_applications .app फ़ाइल की .app कुंजी भी लोड की जाएगी, लेकिन उन्हें प्रारंभ नहीं किया जाएगा।

इसके अलावा, इसमें सूचीबद्ध सभी एप्लिकेशन :applications इस एप्लिकेशन के होने से पहले :applications कुंजी को स्पष्ट रूप से शुरू किया जाना चाहिए। यदि नहीं, तो {:error, {:not_started, app}} को वापस कर दिया जाता है, जहां app गुम एप्लिकेशन का नाम है।

यदि आप स्वचालित रूप से सभी app निर्भरता को लोड और प्रारंभ करना चाहते हैं, तो सुनिश्चित करें कि ensure_all_started/2

type तर्क आवेदन के प्रकार को निर्दिष्ट करता है:

  • :permanent - यदि app समाप्त हो जाता है, तो अन्य सभी एप्लिकेशन और संपूर्ण नोड भी समाप्त हो जाते हैं।

  • :transient - अगर app साथ समाप्त होता है :normal कारण, यह सूचित किया जाता है लेकिन कोई अन्य अनुप्रयोग समाप्त नहीं होते हैं। यदि एक क्षणिक अनुप्रयोग असामान्य रूप से समाप्त हो जाता है, तो अन्य सभी अनुप्रयोग और संपूर्ण नोड भी समाप्त हो जाते हैं।

  • :temporary - यदि app समाप्त हो जाता है, तो यह सूचित किया जाता है लेकिन कोई अन्य एप्लिकेशन समाप्त नहीं होता है (डिफ़ॉल्ट)।

ध्यान दें कि stop/1 कॉल करके किसी एप्लिकेशन को स्पष्ट रूप से रोकना हमेशा संभव है। आवेदन के प्रकार के बावजूद, कोई अन्य अनुप्रयोग प्रभावित नहीं होगा।

यह भी ध्यान दें :transient प्रकार थोड़ा व्यावहारिक उपयोग का है, क्योंकि जब एक पर्यवेक्षण वृक्ष समाप्त होता है, तो इसका कारण होता है :shutdown , :normal नहीं।

start_applications (टाइमआउट \\ 5000)

started_applications(timeout()) :: [
  {app(), description :: charlist(), vsn :: charlist()}
]

वर्तमान में चल रहे अनुप्रयोगों के बारे में जानकारी के साथ एक सूची लौटाता है।

स्टॉप (एप्लिकेशन)

stop(app()) :: :ok | {:error, term()}

दिए गए app बंद कर देता है।

जब रोका गया, तो एप्लिकेशन अभी भी लोड है।

उतारना (ऐप्लिकेशन)

unload(app()) :: :ok | {:error, term()}

दिए गए app लोड करता है।

यह भी सभी को अनलोड करेगा :included_applications । ध्यान दें कि फ़ंक्शन एप्लिकेशन मॉड्यूल को शुद्ध नहीं करता है।

कॉलबैक

prep_stop (स्थिति) (वैकल्पिक)

prep_stop(state()) :: state()

आवेदन रोकने से पहले फोन किया।

शीर्ष स्तर के पर्यवेक्षक के समाप्त होने से पहले यह कार्य कहा जाता है। यह start/2 , अगर यह किया, या [] अन्यथा द्वारा लौटाए गए राज्य को प्राप्त करता है। वापसी मान को बाद में stop/1 लिए पारित किया जाता है stop/1

प्रारंभ (start_type, start_args)

start(start_type(), start_args :: term()) ::
  {:ok, pid()} | {:ok, pid(), state()} | {:error, reason :: term()}

आवेदन शुरू होने पर कॉल किया जाता है।

यह फ़ंक्शन तब कहा जाता है जब किसी एप्लिकेशन को Application.start/2 (और उस के शीर्ष पर फ़ंक्शन, जैसे Application.ensure_started/2 ) का उपयोग करना शुरू किया जाता है। इस फ़ंक्शन को एप्लिकेशन की शीर्ष-स्तरीय प्रक्रिया शुरू करनी चाहिए (जो अनुप्रयोग के पर्यवेक्षण के पेड़ का शीर्ष पर्यवेक्षक होना चाहिए यदि आवेदन पर्यवेक्षण के आसपास ओटीपी डिजाइन सिद्धांतों का पालन करता है)।

start_type परिभाषित करता है कि आवेदन कैसे शुरू किया गया है:

  • :normal - उपयोग किया जाता है यदि स्टार्टअप एक सामान्य स्टार्टअप है या यदि एप्लिकेशन वितरित किया गया है और किसी अन्य नोड से विफलता के कारण चालू नोड पर शुरू किया गया है और एप्लिकेशन विनिर्देश कुंजी :start_phases है :undefined
  • {:takeover, node} - यदि अनुप्रयोग वितरित किया जाता है और नोड node पर विफल होने के कारण वर्तमान नोड पर शुरू किया जाता node
  • {:failover, node} - यदि अनुप्रयोग वितरित किया गया है और नोड node पर विफलता के कारण वर्तमान नोड पर शुरू किया गया है, और एप्लिकेशन विनिर्देश कुंजी :start_phases नहीं है :undefined

start_args आवेदन में दिए गए तर्क हैं :mod विनिर्देशन कुंजी (जैसे, mod: {MyApp, [:my_args]} )।

यदि स्टार्टअप सफल है {:ok, pid, state} तो इस फ़ंक्शन को या तो {:ok, pid} या {:ok, pid, state} वापस करना चाहिए। pid को शीर्ष पर्यवेक्षक का PID होना चाहिए। state एक मनमाना शब्द हो सकता है, और यदि छोड़ दिया जाएगा तो डिफ़ॉल्ट रूप से [] ; यदि आवेदन को बाद में रोक दिया जाता है, तो state को stop/1 कॉलबैक पर stop/1 दिया जाता है (अधिक जानकारी के लिए stop/1 कॉलबैक के लिए प्रलेखन देखें)।

use Application start/2 कॉलबैक के लिए कोई डिफ़ॉल्ट कार्यान्वयन प्रदान नहीं करता है।

start_phase (चरण, start_type, phase_args) (वैकल्पिक)

start_phase(phase :: term(), start_type(), phase_args :: term()) ::
  :ok | {:error, reason :: term()}

तुल्यकालिक चरणों में एक आवेदन शुरू करें।

इस फ़ंक्शन को start/2 फिनिश के बाद लेकिन Application.start/2 रिटर्न से पहले कहा जाता है। इसे उस क्रम में सूचीबद्ध किए गए एप्लिकेशन (और किसी भी शामिल एप्लिकेशन) विनिर्देश में परिभाषित प्रत्येक प्रारंभ चरण के लिए एक बार बुलाया जाएगा।

स्टॉप (राज्य)

stop(state()) :: term()

एक आवेदन को रोकने के बाद कॉल किया गया।

यह फ़ंक्शन किसी एप्लिकेशन को रोक दिए जाने के बाद कहा जाता है, अर्थात, इसके पर्यवेक्षण के पेड़ को रोकने के बाद। यह start/2 कॉलबैक क्या किया के विपरीत करना चाहिए, और किसी भी आवश्यक सफाई प्रदर्शन करना चाहिए। इस कॉलबैक का रिटर्न मान अनदेखा किया गया है।

state start/2 , अगर यह किया है, या [] अन्यथा द्वारा लौटाया गया state है। यदि वैकल्पिक कॉलबैक prep_stop/1 मौजूद है, तो इसके बजाय state इसका रिटर्न मान है।

use Application इस फ़ंक्शन के डिफ़ॉल्ट कार्यान्वयन को परिभाषित करता है जो कुछ भी नहीं करता है और बस रिटर्न करता है :ok