On Wed, Dec 5, 2018 at 12:07 PM Stanislav Lobanov wrote:
>
> I'm very sorry but I absolutely forgot to mention a problem with primary keys.
>
> As i said, all objects in the database have id, start and end primary keys.
>
> CREATE TABLE parent (
> id SERIAL NOT NULL,
> start TIMESTAMP WITHOUT
On Wed, Dec 5, 2018 at 11:04 AM Chris Wilson
wrote:
>
> Dear Mr Bayer and SQLAlchemy users,
>
>
>
> We have an issue which probably counts as a feature request rather than a
> bug, because it’s sufficiently esoteric. We need to be able to use some
> Mappers (in one Metadata) while other mappers
My 2c about table design (not SQLA): I would suggest having a child with
just id, a parent table with just id and child_id (foreign key to
child.id), and then store additional "versioned" data in separate
parent_history and child_history tables that have foreign keys only to
their respective
I'm very sorry but I absolutely forgot to mention a problem with primary
keys.
As i said, all objects in the database have id, start and end primary keys.
CREATE TABLE parent (
id SERIAL NOT NULL,
start TIMESTAMP WITHOUT TIME ZONE NOT NULL,
end TIMESTAMP WITHOUT TIME ZONE NOT NULL,
data
Dear Mr Bayer and SQLAlchemy users,
We have an issue which probably counts as a feature request rather than a bug,
because it's sufficiently esoteric. We need to be able to use some Mappers (in
one Metadata) while other mappers (in a different Metadata) are not and cannot
be completely
I have re-read our dialogue and the new FilteredQuery example and decided
to use following approach:
1. single table versioning
2. global filtering with temporal options
That way i can have whole history in one table and force application to use
only "latest" object versions. I agree that in
On Wed, Dec 5, 2018 at 2:42 AM Stanislav Lobanov wrote:
>
> First of all, thank you for such a detailed answer. Thank you for sharing
> your experience and continued support.
>
> Now i understand that using database views is not the best approach. In the
> previous project we used an approach
