On Fri, Dec 28, 2018 at 1:29 AM Stanislav Lobanov wrote:
>
> Hello again, i'm bumping this thread to pop a context for a further
> discussion.
>
> I'm using this VersionedStartEnd approach and i think that i found a bug.
>
> Consider that there are Child instance and Parent instance:
>
> Parent
Hello again, i'm bumping this thread to pop a context for a further
discussion.
I'm using this VersionedStartEnd approach and i think that i found a bug.
Consider that there are Child instance and Parent instance:
Parent
id | start | end | data| child_id
1 | 2018-01-01
Great explanation, thank you very much.
I think that in case one uses versioned approach with changing ids then is
it better to have some automated function that will make
"expire-changestate-readd" dance by introspecting relations on the object,
because if a programmer forget to override
On Sun, Dec 9, 2018 at 11:22 AM Stanislav Lobanov wrote:
>
> Hello, i have one more question:
>
> there is a Child definition:
>
> class Child(VersionedStartEnd, Base):
> __tablename__ = "child"
>
> id = Column(Integer, primary_key=True, autoincrement=True)
> start = Column(DateTime,
Hello, i have one more question:
there is a Child definition:
class Child(VersionedStartEnd, Base):
__tablename__ = "child"
id = Column(Integer, primary_key=True, autoincrement=True)
start = Column(DateTime, primary_key=True)
end = Column(DateTime, primary_key=True)
data =
That is great, i hope it will help someone as it helped me :)
P.S.: i have played a bit with your POC implementation and it works very
well. I'm thinking about adding MapperOptions to add low-level control on
how specific query entity should be selected (for example, i want latest
version of
I'm going to add this to the examples at
https://docs.sqlalchemy.org/en/latest/orm/examples.html#module-examples.versioned_rows
since it has this new twist of doing both UPDATE and INSERT, if that's
OK with you
On Fri, Dec 7, 2018 at 1:20 AM Stanislav Lobanov wrote:
>
> Thank you so much, Mike!
>
Thank you so much, Mike!
Did not tried it yet, but it looks like you nailed it :) I'll check the
sources on holidays.
With the deepest respect,
Stanislav.
четверг, 6 декабря 2018 г., 22:41:20 UTC+3 пользователь Mike Bayer написал:
>
> given that it looks like a new version for you means an
given that it looks like a new version for you means an UPDATE of the
old row and an INSERT of the new, here is that, which is again
basically what we see at
https://docs.sqlalchemy.org/en/latest/_modules/examples/versioned_rows/versioned_rows.html
with some extra steps to emit the UPDATE for the
On Thu, Dec 6, 2018 at 3:53 AM Stanislav Lobanov wrote:
>
> Example business case is:
>
> Parent and child are added to the system (current date is 2018-01-01)
>
> Parent
> id | start | end | data| child_id
> 1 | 2018-01-01| 2018-01-11 | c1 | 1 # just
>
> given that now() is the current time, how do you determine "end' when
> writing these rows? "end" must always be a date that's in the
> future?What happens when now() passes "end", you get None for your
> object?
>
When new object is created the "end" date is automatically (or
On Thu, Dec 6, 2018 at 3:53 AM Stanislav Lobanov wrote:
>
> Example business case is:
>
> Parent and child are added to the system (current date is 2018-01-01)
>
> Parent
> id | start | end | data| child_id
> 1 | 2018-01-01| 2018-01-11 | c1 | 1 # just
Example business case is:
Parent and child are added to the system (current date is 2018-01-01)
Parent
id | start | end | data| child_id
1 | 2018-01-01| 2018-01-11 | c1 | 1 # just pointer
to child with some id (now points to first child record)
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
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
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
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 with Query objects that were using
WHERE statements to filter needed
19 matches
Mail list logo
