Heus Habr!
Pergimus ad investigationes thema ΠΈ , inter in gradu datorum. Hodie te ad legendum invitamus cur, cum magnas applicationes excogitantes, structuram datorum, non codicem Iavarum, sit magni momenti, quomodo hoc fiat, et quae exceptiones ad hanc regulam pertineant.
In hoc pressiore articulo, cur credam in omnibus fere casibus, exemplar notitiae applicationis designari "ex datorum datorum" potius quam "ex facultatibus Javae" (vel quacunque lingua clientis es. adque). Secundum accessum accipiendo, ad longam doloris et doloris semitam te disponis, semel incepta crescere incipit.
Articulus scriptum est secundum data in Stack Overflow.
Interesting disputationibus de reddit in sectionibus ΠΈ .
Code generation
Quam miratus sum, tam parvam partem usorum esse qui, cognita jOOQ, indignantur quod jOOQ gravissime nititur in codice generationis ad operandum. Nemo te prohibet, jOOQ uti tibi visum est, aut codice generationi uti cogens. Defectus autem (ut in manibus descriptus) modus operandi cum jOOQ est ut incipe schemate datorum (legato) datorum, contra ipsum utens codicem generantis ad jOOQ ut inde constituas classes repraesentantes tabulas tuas, et tunc scribe genus. - tutum queries ad has tabulas;
for (Record2<String, String> record : DSL.using(configuration)
// ^^^^^^^^^^^^^^^^^^^^^^^ ΠΠ½ΡΠΎΡΠΌΠ°ΡΠΈΡ ΠΎ ΡΠΈΠΏΠ°Ρ
Π²ΡΠ²Π΅Π΄Π΅Π½Π° Π½Π°
// ΠΎΡΠ½ΠΎΠ²Π°Π½ΠΈΠΈ ΡΠ³Π΅Π½Π΅ΡΠΈΡΠΎΠ²Π°Π½Π½ΠΎΠ³ΠΎ ΠΊΠΎΠ΄Π°, Π½Π° ΠΊΠΎΡΠΎΡΡΠΉ ΡΡΡΠ»Π°Π΅ΡΡΡ ΠΏΡΠΈΠ²Π΅Π΄Π΅Π½Π½ΠΎΠ΅
// Π½ΠΈΠΆΠ΅ ΡΡΠ»ΠΎΠ²ΠΈΠ΅ SELECT
.select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
// vvvvv ^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ΡΠ³Π΅Π½Π΅ΡΠΈΡΠΎΠ²Π°Π½Π½ΡΠ΅ ΠΈΠΌΠ΅Π½Π°
.from(ACTOR)
.orderBy(1, 2)) {
// ...
}Signum generatur aut manually extra ecclesiam, aut manually in unaquaque ecclesia. sicut talis regeneratio immediate sequitur .
Source code generation
Sunt variae philosophicae, commoda et incommoda cum his accessionibus ad codicem generationis β manualis et latis associati β quod in hoc articulo singillatim non disputo. Sed in universum totum codicem generati punctum est, quod in Iava nobis permittit referre illam "veritatem" quam supponitur, sive intra nostram sive extra. Quodammodo, hoc faciunt compilatores cum bytecode, machinae codicem vel aliam formam fontis codicem gignunt - repraesentationem "veritatis" nostrae in alia lingua, quoad rationes specificas, consequimur.
Tales sunt plures codicem generantium. Exempli gratia . Principium semper idem est;
- Est aliqua veritas (interna vel externa) exempli gratia, specificatio, exemplar data, etc.
- Locus huius veritatis in programmatione linguae nostrae repraesentatione indigemus.
Praeterea fere semper expedit talem repraesentationem generare ad evitandam redundantiam.
Type Suggero and Annotation Processing
Nota: alia magis moderna et specifica accessus ad codicem generandum pro jOOQ utitur provisoribus speciebus; . In hoc casu, signum a compilator generatur, actu in scaena compilatione. In principio tale signum non est in forma fontali. Java similes, licet non elegantes, instrumentorum processus annotationis, e.g. .
Aliquo modo eadem hic accidunt ac in primo casu, excepto;
- codicem genitum non vides (fortasse res haec alicui minus foeda videtur?)
- Providendum est ut typi praeberi possint, id est "verum" semper praesto esse debent. Hoc facile est in casu Lombok, qui annotat Β« veritatem Β». Est paulo implicatius cum exemplaribus datorum quae constanti promptu pendent nexu vivo.
Quid est quaestio de codice generationis?
Praeter captiosam quaestionem quomodo optimum codicem generationis - manually vel automatice curreret, etiam commemorare debemus homines qui credunt codicem generationis minime egere. Causa huius sententiae, quam saepissime incidi, est tum difficile pipelineum constituere. Etiam difficile est. Additae infrastructurae sumptuum oriuntur. Si modo incipit cum certo productum (sive jOOQ, sive JAXB, sive Hibernate, etc.), constituens ambitus productionis temporis operam dat ut discentes ipsum API potius habe ut inde valorem elicias. .
Si impensae ad intellegendum structuram generantis nimis altae sunt, tunc quidem API pauper officium fecit in usabilitate codici generantis (et postea evenit ut usor usorum in ea etiam complexus sit). Usability debet esse summa prioritas API cuilibet talium. Sed hoc est unum argumentum contra codicem generationis. Alioquin omnino manuale omnino est scribere repraesentationem localem veritatis internae vel externae.
Multi dicunt se omnia haec facere tempus non habere. Nam cursus ullamcorper mi eget luctus. Aliquando vectores purgabimus, tempus habebimus. respondebo illis;
,
Sed in Hibernate/JPA tam facile est codicem Iava scribere.
Vere. Hibernate enim et eius utentes, hoc est et benedictio et maledictio. In Hibernate potes tantum scribere duo entia, ut hoc;
@Entity
class Book {
@Id
int id;
String title;
}et omnia fere parata sunt. Nunc ad Hibernate est generare complexum "details" quam exacte haec entitas in DDL tui SQL "dialecti" definietur;
CREATE TABLE book (
id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
title VARCHAR(50),
CONSTRAINT pk_book PRIMARY KEY (id)
);
CREATE INDEX i_book_title ON book (title);Cursus eu mauris ac elit. A re refrigerandi occasio cito incipiendi et diversa tentanda est.
Sed, quaeso, sinas. iacebam.
- Nunquid Hiberna in actu definitionem huius nominis primariae clavem urgebit?
- Numquid Hibernate indicem in TITULO creabit? - Pro certo scio nos hoc egere.
- Hibernate prorsus faciet hanc clavem distinguendi in Identity Specification?
Verisimile non est. Si consilium tuum de scabere explicas, semper commodum est ad simpliciter antiquam datorum abiiciendam et novam generandam quamprimum necessarias annotationes addas. Sic Liber entitatis tandem formam habebit;
@Entity
@Table(name = "book", indexes = {
@Index(name = "i_book_title", columnList = "title")
})
class Book {
@Id
@GeneratedValue(strategy = IDENTITY)
int id;
String title;
}
Frigus. Renati. Iterum hoc casu facillimum erit in principio.
Sed reddere tibi postea pro eo
Serius aut citius in productionem habebis. Hoc exemplar cum opere cessabit. Quod:
In productione iam non poterit, si opus est, deponere vetus database et a scabere incipere. Tibi database legatum fiet.
Ex hoc nunc et usque in aeternum debebis scribere . Quid entia in hac causa fiet? Aut manually accommodare potes (et sic inposuit duplicare), vel dicere Hibernate potes eas tibi regenerare (quam verisimile est generatos hoc modo ad exspectationem tuam occurrere?) Utroque modo perdis.
Cum ergo productionem ingredieris, inaequalis calido indigebis. Atque in productione celerrime opus est. Quia non parasti nec lenis fistulam migrationum tuarum ad productionem instituisti, omnia truculenter repeciare. Et tunc non vacat tibi omnia recte facere. Hibernate reprehendis, quod semper alterius culpa est, modo non tu...
Sed a principio omnino aliter fieri potuit. Exempli gratia, rotae rotundae in birota positae.
Database primum
Veritas "veritas" in schemate datorum vestro ac "principatus" in datorum positum est. Schema definitur tantum in ipso database et nusquam alibi, et uterque client exemplar huius schematis habet, ita perfectum sensum obtemperet schema obsequio eius et integritati, ut ius faciat in database - ubi delatione est. condita.
Haec vetus est, etiam pervulgata sapientia. Claves primariae et unicae sunt bonae. Alienae claves bonae sunt. Reprehendo restrictiones bona est. - Fine.
Etiam id neque enim. Exempli gratia, oraculo utens, probabiliter denotare vis:
- Quid est tablespace in mensa?
- Quid est valorem suum PCTFREE?
- Quid est cache magnitudine in ordine (post id)
Hoc in parvis systematibus magni momenti esse non potest, sed non exspectandum est donec in magnas notitias regni movearis--proficere potes a venditore, dummodo optimizationes repositae sicut praedictae multo citius. Nullae ORMs quas vidi (including jOOQ) accessum praebent ad plenam optionum DDL optionum quas in database tuo uti velis. ORMs nonnulla instrumenta praebent quae auxilium scribis DDL.
Sed in fine diei, ambitus bene designatus manu DDL scriptus est. Quaelibet generata DDL approximatio tantum eius est.
Quid de clientis exemplar?
Ut supra, in cliente exemplar desiderabis schematis database tui, intuitu clientis. Supervacaneum est memorare, hic sententia clientis sync cum actuali exemplari esse debet. Quid hoc optume assequi? Codice utens genitor.
Omnes databases meta informationes suas per SQL praebent. Ecce quomodo omnes tabulas ex tuis database in diversis dialectis SQL accipias:
-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables
-- DB2
SELECT tabschema, tabname
FROM syscat.tables
-- Oracle
SELECT owner, table_name
FROM all_tables
-- SQLite
SELECT name
FROM sqlite_master
-- Teradata
SELECT databasename, tablename
FROM dbc.tables
Hae interrogationes (vel similes, secundum an etiam opiniones, opiniones materiales, functiones mensas aestimandas) considerare necesse habeant, vocando etiam exsecuti sunt. ex JDBC, seu jOOQ meta-moduli utens.
Ex eventibus talium inquisitionum, faciliter est generare quamlibet clientis partem repraesentationem exemplaris tui database, cuiuscumque technologiae in cliente uteris.
- Si JDBC vel Ver uteris, statuto chordae constantes creare potes
- Si JPA uteris, res ipsas generare potes
- Si jOOQ uteris, generare potes jOOQ meta-exemplaris
Prout quantum functionis offertur a cliente tuo API (eg jOOQ vel JPA), meta generatae exemplar vere dives esse potest et perfectus. Exempli gratia, possibilitas implicita coniungit; , quod meta generatae innititur informationes de relationibus clavibus exteris quae inter tabulas tuas exstant.
Nunc quodlibet incrementum datorum statim clientem codicem renovabit. Finge exempli gratia:
ALTER TABLE book RENAME COLUMN title TO book_title;Visne vere hoc officium bis facere? Nullo casu. Simpliciter committe DDL, eam per edificandi fistulam currendi et entitatem renovatam obtine;
@Entity
@Table(name = "book", indexes = {
// ΠΡ ΠΎΠ± ΡΡΠΎΠΌ Π·Π°Π΄ΡΠΌΡΠ²Π°Π»ΠΈΡΡ?
@Index(name = "i_book_title", columnList = "book_title")
})
class Book {
@Id
@GeneratedValue(strategy = IDENTITY)
int id;
@Column("book_title")
String bookTitle;
}Aut renovatum jOOQ genus. Plurimae DDL mutationes etiam semanticas afficiunt, non solum syntaxin. Ideo utile erit in codice compilata inspicere ut videre quidnam e codice tuo incremento datorum (vel) afficiatur.
Sola veritas
Quidquid technologiae uteris, unum semper exemplar est quod unicum veritatis principium est alicuius subsystematis β vel, minimum, ad hoc conandum et talem incepti confusionem vitandam, ubi "veritas" ubique est et nusquam simul. . Omnia multo simpliciora esse potuerunt. Si modo XML lima cum alia ratione permutans, XSD tantum utere. Vide ad INFORMATION_SCHEMA meta exemplar ab jOOQ in XML forma:
- XSD bene intellegitur
- XSD signa XML contentus optime et sanationem in omnibus linguis clientis concedit
- XSD bene vertit et retro processit convenientiae
- XSD interpretari possunt in codice Javae utens XJC
Ultimum punctum interest. Cum communicando cum externa ratione utens XML nuntiis, volumus certa nuntia nostra valida esse. Hoc facillime ad usus JAXB, XJC et XSD assequendum est. Mera insania est cogitare, cum consilio "Java primo" accedere quo epistulas nostras sicut Java objecta facimus, aliquo modo ad XML deformatum et ad alia ratio consummationis emissa. XML ita generata esset valde exiguus, undocumentatus et difficilis ad explicandum. Si consensus campi muneris (SLA) pro tali instrumento erat, statim illud cochleare volumus.
Honeste hoc fit omni tempore cum JSON APIs, sed quod est alia fabula, iterum litigabo.
Databases: idem es
Cum opus databases, cognoscis eas omnes plerumque similes esse. Basis notitias suas habet et rationem administrare debet. Modificationes quaevis schemate factae directe in DDL perficiantur ut unus veritatis fons renovetur.
Cum fons renovatio incidit, omnes clientes etiam exemplaribus suis renovare debent. Aliqui clientes in Java scribi possunt utentes jOOQ et Hibernate vel JDBC (vel utroque). Alii clientes in Perl scribi possunt (modo eos fortuna volumus), alii in C# scribi possunt. Nihil refert. Exemplar principale est in database. Exempla generata ORMs utens plerumque vilis notae sunt, male descriptae et difficiles ad explicandum.
Noli ergo errare. Noli ab initio errare. Opus datorum a. Aedificare instruere pipelinum quod automated potest. Admitte generantibus codicem ut facilem exemplar datorum exscribere et in clientibus effundere. De codice generantibus et desine. Boni sunt. Cum his fies fertilior. Te solum exiguum tempus ab ipso exordio constituendo impendere debes - deinde anni auctae productivitatis te exspectant, qui historiam tui propositi efficiunt.
Non mihi tamen, postea.
cuius evidentiam
Ut pateat: Hoc articulum nullo modo advocati debes flectere totam rationem (i.e., domain, logicam negotiationem, etc., etc.) ad exemplar datorum aptare. Quod dico in hoc articulo est de codice clientis qui inter se datorum datorum secundum exemplar datorum agere debet, ut ipsa non exprimat exemplar datorum in statu "primo-classis". Haec logica plerumque collocatur in tabulario notitiae accessus in cliente tuo.
In duo architecturae planae, quae adhuc aliquibus in locis conservantur, exemplar huius systematis unum tantum esse potest. Sed in plerisque systematibus tabulatum accessum notitiarum mihi videtur esse "subsystem" quod exemplar datorum encapsulat.
dictarum excepcionium
Exceptiones omni regulae sunt, et iam dixi generationi datorum-primo et principii accedere posse interdum ineptum esse. Hic duae exceptiones (sunt probabiliter aliae);
- Quando schema ignotum est et de necessitate cognoscendi. Exempli gratia, provisor es instrumenti quod utentes adiuvat navigare aliquem schemate. Ugh. Non est hic generatio codicis. Sed tamen prima datorum praecedit.
- Cum autem circuitus generari debet in musca ad aliquod problema solvendum. Hoc exemplum videtur quasi versio leviter poetica exemplaris , i.e., vere non habes rationem clare definitam. Hoc in casu, saepe ne scias quidem potes RDBMS congruere.
Exceptiones sunt natura eximiae. In pluribus de usu RDBMS, schema praecognitum est, in RDBMS residet et unicus fons "veritatis" est, omnesque clientes habent exemplaria ex eo derivata acquirere. Specimen, genitore codice uti debes.
Source: www.habr.com