MariaDB Connector/Python enables python programs to access MariaDB
and MySQL databases, using an API which is compliant with the Python
DB API 2.0 (PEP-249). It is written in C and Python and uses MariaDB
Connector/C client library for client server communication.
WWW: https://www.github.com/mariadb-corporation/mariadb-connector-python
PR: 275157
sqloxide wraps rust bindings for sqlparser-rs into a python package using pyO3.
The original goal of this project was to have a very fast, efficient, and
accurate SQL parser I could use for building data lineage graphs across large
code bases (think hundreds of auto-generated .sql files). Most existing sql
parsing approaches for python are either very slow or not accurate (especially
in regards to deeply nested queries, sub-selects and/or table aliases). Looking
to the rust community for support, I found the excellent sqlparser-rs crate
which is quite easy to wrap in python code.
Solid Queue is a DB-based queuing backend for Active Job, designed with
simplicity and performance in mind.
Besides regular job enqueuing and processing, Solid Queue supports delayed jobs,
concurrency controls, recurring jobs, pausing queues, numeric priorities per
job, priorities by queue order, and bulk enqueuing (enqueue_all for Active Job's
perform_all_later).
Solid Queue can be used with SQL databases such as MySQL, PostgreSQL or SQLite,
and it leverages the FOR UPDATE SKIP LOCKED clause, if available, to avoid
blocking and waiting on locks when polling jobs. It relies on Active Job for
retries, discarding, error handling, serialization, or delays, and it's
compatible with Ruby on Rails's multi-threading.
Solid Cache is a database-backed Active Support cache store that let's you keep
a much larger cache than is typically possible with traditional memory-only
Redis or Memcached stores. This is thanks to the speed of modern SSD drives,
which make the access-time penalty of using disk vs RAM insignificant for most
caching purposes. Simply put, you're now usually better off keeping a huge cache
on disk rather than a small cache in memory.
Solid Cable is a database-backed Action Cable adapter that keeps messages in a
table and continously polls for updates. This makes it possible to drop the
common dependency on Redis, if it isn't needed for any other purpose. Despite
polling, the performance of Solid Cable is comparable to Redis in most
situations. And in all circumstances, it makes it easier to deploy Rails when
Redis is no longer a required dependency for Action Cable functionality.
Active Record connects classes to relational database tables to establish an
almost zero-configuration persistence layer for applications. The library
provides a base class that, when subclassed, sets up a mapping between the new
class and an existing table in the database. In the context of an application,
these classes are commonly referred to as models. Models can also be connected
to other models; this is done by defining associations.
Active Record relies heavily on naming in that it uses class and association
names to establish mappings between respective database tables and foreign key
columns. Although these mappings can be defined explicitly, it's recommended to
follow naming conventions, especially when getting started with the library.
Active Model provides a known set of interfaces for usage in model classes. They
allow for Action Pack helpers to interact with non-Active Record models, for
example. Active Model also helps with building custom ORMs for use outside of
the Rails framework.
Active Model provides a default module that implements the basic API required to
integrate with Action Pack out of the box: ActiveModel::API.
Basic SQLAlchemy driver for DuckDB
Once you've installed this package, you should be able to just use it,
as SQLAlchemy does a python path search
WWW: https://github.com/Mause/duckdb_engine
PR: 278138
Based on xtrabackup83 port, with corresponding changes, including:
- usage of bundled boost
- disable build on 32bit platforms (unsupported by vendor)
- new patches from mysql-server84.
2024-09-01 databases/mysql81-server: MySQL 8.1 is not supported by the vendor and has unfixed vulnerabilies
2024-09-01 databases/mysql81-client: MySQL 8.1 is not supported by the vendor and has unfixed vulnerabilies
SQL is code. Write it, version control it, comment it, and run it using files.
Writing your SQL code in Python programs as strings doesn't allow you to easily
reuse them in SQL GUIs or CLI tools like psql. With aiosql you can organize
your SQL statements in .sql files, load them into your python application as
methods to call without losing the ability to use them as you would any other
SQL file.
https://pypi.org/project/aiosql/
This port is based on ldb25. The changes are:
- Fix checks for Python support
The bsd.port.pre.mk was included too early and USES=python wasn't
processed as expected. As a result, the checks for Python support were
broken.
- Switch from waf to configure and make.
Upstream wants us to do it this way. Otherwise, the build system
produces the following error message:
> ===> Configuring for ldb28-2.8.1
> PYTHONHASHSEED=1 missing! Don't use waf directly, use ./configure and make!
So, set HAS_CONFIGURE and BINARY_ALIAS to make the port build without
waf.
- Clean up the makefile (sort variables and fix indentation)
- Drop the NO_PYTHON variable. It complicates the makefile
unnecessarily. It is still possible to disable Python support by
configuring the PYTHON3 option.
- Use WITH_DEBUG instead of option DEBUG.
- Enable PYTHON3 by default.
The PYTHON3 option is required by net/samba419 to build without the
bundled dependencies. The primary purpose of databases/ldb28 is to
make it possible, so enable Python support by default.
PR: 280510
Sponsored by: Klara, Inc.
The XRootD project provides a high-performance, fault-tolerant, and secure
solution for handling massive amounts of data distributed across multiple
storage resources, such as disk servers, tape libraries, and remote sites. It
enables efficient data access and movement in a transparent and uniform manner,
regardless of the underlying storage technology or location. It was initially
developed by the High Energy Physics (HEP) community to meet the data storage
and access requirements of the BaBar experiment at SLAC and later extended to
meet the needs of experiments at the Large Hadron Collider (LHC) at CERN. XRootD
is the core technology powering the EOS distributed filesystem, which is the
storage solution used by LHC experiments and the storage backend for CERNBox.
XRootD is also used as the core technology for global CDN deployments across
multiple science domains.
XRootD is based on a scalable architecture that supports multi-protocol
communications. XRootD provides a set of plugins and tools that allows the user
to configure it freely to deploy data access clusters of any size, and which can
include sophisticated features such as erasure coded files, various methods of
authentication and authorization, as well as integration with other storage
systems like ceph.
This port is the Python binding for XRootD.
SQL::SplitStatement is a simple module which tries to split any SQL code, even
including non-standard extensions, into the atomic statements it is composed of.
The logic used to split the SQL code is more sophisticated than a raw split on
the ; (semicolon) character: first, various different statement terminator
tokens are recognized (see below for the list), then this module is able to
correctly handle the presence of said tokens inside identifiers, values,
comments, BEGIN ... END blocks (even nested), dollar-quoted strings, MySQL
custom DELIMITERs, procedural code etc., as (partially) exemplified in the
"SYNOPSIS" above.
Consider however that this is by no means a validating parser (technically
speaking, it's just a context-sensitive tokenizer). It should rather be seen as
an in-progress heuristic approach, which will gradually improve as test cases
will be reported. This also means that, except for the "LIMITATIONS" detailed
below, there is no known (to the author) SQL code the most current release of
this module can't correctly split.
The Cego Python driver enables Python programs to access cego databases,
using an API which is compliant with the Python DB API 2.0 (PEP-249).
It is written in C and uses the Cego C wrapper client library for
client server communication.
This implementation is derived from the MariaDB Connector written
by Georg Richter.
* This is an LTS version.
* the mysql command now generates a warning about deprecation.
to prevent these for other ports with USES=mysql Mk/Uses/mysql.mk
has been patched.
