%global _empty_manifest_terminate_build 0 Name: python-sqly Version: 0.7.0 Release: 1 Summary: Write SQL in SQL License: MPL 2.0 URL: https://github.com/BlackEarth/sqly Source0: https://mirrors.nju.edu.cn/pypi/web/packages/5a/97/de5f9156e38dc555b37c6981d3c1918a1cfab3692ca30059cf633045c61f/sqly-0.7.0.tar.gz BuildArch: noarch Requires: python3-click Requires: python3-networkx Requires: python3-pydantic Requires: python3-PyYAML %description # sqly SQL is a fantastic language — one of the most successful programming languages in the world. We should use it, not try to replace it with a bespoke DSL. Yet there are a couple of things that are nice to have help with in constructing SQL queries: * **dialect-aware safe value substitution**: Every database interface has its own syntax for substituting values safely (not to allow SQL injection) — for example, `$1` or `?` or `:varname`. They also have different requirements for the format of the sql + values argument lists. I want to able to write my queries with the same value substituion syntax, regardless of which database interface I am using, and know that the SQL will be output correctly for my interface, and that the values will be passed to the database engine safely. * **dynamic attributes**: In many applications, I don't know in advance which attributes I am going to select, insert, update, or filter by. I want to SELECT a given list of attributes, or filter WHERE a given key/value mapping, or UPDATE or INSERT particular attributes, without having to rewrite the SQL query. * **block composition**: Some SQL queries are very complex. I want to able to compose blocks of SQL into larger queries, so that I can manage this complexity effectively. (Most database query DSLs are unable to deal with complex queries, or they invent a hard-to-learn language for writing those queries. Learning SQL is a better use of our time, but it would be very helpful having some assistance managing/manipulating the different blocks in a query.) sqly: * One class, `SQL`, with one field, `query`, and one method, `.render`, which takes one optional argument, `dialect`. * Dynamic value replacement, rendered in one of the supported dialects: postgres (`$1`), sqlalchemy (`:varname`), embedded (`:varname`), mysql (`%(varname)s`), sqlite (`?`). Default style is embedded / `:varname`. * Dynamic attribute/value lists in `SELECT`, `WHERE`, `INSERT`, and `UPDATE` syntax * Block composition %package -n python3-sqly Summary: Write SQL in SQL Provides: python-sqly BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-sqly # sqly SQL is a fantastic language — one of the most successful programming languages in the world. We should use it, not try to replace it with a bespoke DSL. Yet there are a couple of things that are nice to have help with in constructing SQL queries: * **dialect-aware safe value substitution**: Every database interface has its own syntax for substituting values safely (not to allow SQL injection) — for example, `$1` or `?` or `:varname`. They also have different requirements for the format of the sql + values argument lists. I want to able to write my queries with the same value substituion syntax, regardless of which database interface I am using, and know that the SQL will be output correctly for my interface, and that the values will be passed to the database engine safely. * **dynamic attributes**: In many applications, I don't know in advance which attributes I am going to select, insert, update, or filter by. I want to SELECT a given list of attributes, or filter WHERE a given key/value mapping, or UPDATE or INSERT particular attributes, without having to rewrite the SQL query. * **block composition**: Some SQL queries are very complex. I want to able to compose blocks of SQL into larger queries, so that I can manage this complexity effectively. (Most database query DSLs are unable to deal with complex queries, or they invent a hard-to-learn language for writing those queries. Learning SQL is a better use of our time, but it would be very helpful having some assistance managing/manipulating the different blocks in a query.) sqly: * One class, `SQL`, with one field, `query`, and one method, `.render`, which takes one optional argument, `dialect`. * Dynamic value replacement, rendered in one of the supported dialects: postgres (`$1`), sqlalchemy (`:varname`), embedded (`:varname`), mysql (`%(varname)s`), sqlite (`?`). Default style is embedded / `:varname`. * Dynamic attribute/value lists in `SELECT`, `WHERE`, `INSERT`, and `UPDATE` syntax * Block composition %package help Summary: Development documents and examples for sqly Provides: python3-sqly-doc %description help # sqly SQL is a fantastic language — one of the most successful programming languages in the world. We should use it, not try to replace it with a bespoke DSL. Yet there are a couple of things that are nice to have help with in constructing SQL queries: * **dialect-aware safe value substitution**: Every database interface has its own syntax for substituting values safely (not to allow SQL injection) — for example, `$1` or `?` or `:varname`. They also have different requirements for the format of the sql + values argument lists. I want to able to write my queries with the same value substituion syntax, regardless of which database interface I am using, and know that the SQL will be output correctly for my interface, and that the values will be passed to the database engine safely. * **dynamic attributes**: In many applications, I don't know in advance which attributes I am going to select, insert, update, or filter by. I want to SELECT a given list of attributes, or filter WHERE a given key/value mapping, or UPDATE or INSERT particular attributes, without having to rewrite the SQL query. * **block composition**: Some SQL queries are very complex. I want to able to compose blocks of SQL into larger queries, so that I can manage this complexity effectively. (Most database query DSLs are unable to deal with complex queries, or they invent a hard-to-learn language for writing those queries. Learning SQL is a better use of our time, but it would be very helpful having some assistance managing/manipulating the different blocks in a query.) sqly: * One class, `SQL`, with one field, `query`, and one method, `.render`, which takes one optional argument, `dialect`. * Dynamic value replacement, rendered in one of the supported dialects: postgres (`$1`), sqlalchemy (`:varname`), embedded (`:varname`), mysql (`%(varname)s`), sqlite (`?`). Default style is embedded / `:varname`. * Dynamic attribute/value lists in `SELECT`, `WHERE`, `INSERT`, and `UPDATE` syntax * Block composition %prep %autosetup -n sqly-0.7.0 %build %py3_build %install %py3_install install -d -m755 %{buildroot}/%{_pkgdocdir} if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi pushd %{buildroot} if [ -d usr/lib ]; then find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/lib64 ]; then find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/bin ]; then find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/sbin ]; then find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst fi touch doclist.lst if [ -d usr/share/man ]; then find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst fi popd mv %{buildroot}/filelist.lst . mv %{buildroot}/doclist.lst . %files -n python3-sqly -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Wed May 31 2023 Python_Bot - 0.7.0-1 - Package Spec generated