<div dir="ltr">Hi Mark, Nikola, David<div><br></div><div style>Our work is not just in case of unifying. It improves the situation in all project (not only in Nova). </div><div><br></div><div><br></div><div style>I would like to say my opinion about DB Archiving also ;) </div>
<div style><br></div><div style>Let start from the problem, abstract solution, current solution, and why this solution is ok. </div><div style><br></div><div style>*) Problem.</div><div style>Records from DB are not deleted at all, so our DB will die. </div>
<div style>*) Abstract solution</div><div style>We should somehow remove old records, I see only one solution, create shadow tables and have a utilities that are smart and could remove data in such way, that shadow and main table are absolutly independent. </div>
<div style>*) Current solution</div><div style>1) Create shadow tables</div><div style>2) Simple utils that move from table to shadow table deleted records</div><div style><br></div><div style>*) Problems in current solution. </div>
<div style>If we just move deleted records to shadow table we have to do all joins (like in Nikola's migration). </div><div style><br></div><div style>So the problem is not in approach of shadow tables, problem is in current utils that are not enough smart.<br>
</div><div style>And in oslo there is only code (that allows to create_shadow table and that check that shadow tables and main are synced) </div><div style><br></div><div style>And one more nit such migrations (as made Nikola) are pretty rare. <br>
</div><div style><br></div><div style>So I don't see any reason to block this DB Archiving code in oslo and block this approach. It could be improved not replaced.</div><div style>More than we are ready to improve it. <br>
</div><div style><br></div><div style><br></div><div style>Best regards,</div><div style>Boris Pavlovic</div><div><div><br></div><div><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br>
</div><div style><br></div><div style><br></div><div style><br></div><div style><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 9, 2013 at 3:05 PM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 2013-07-08 at 14:15 +0200, Nikola Đipanov wrote:<br>
> On 05/07/13 14:26, Boris Pavlovic wrote:<br>
> > Hi all,<br>
> ><br>
> > I would like to explain very high level steps of our work:<br>
> > 1) Sync work with DB in all projects (We have what we have, let it be in<br>
> > one place)<br>
> > 2) Refactor work with DB in one place (not independently in all projects)<br>
> ><br>
> > So I understand that our code around DB is not ideal, but let it be in<br>
> > one place at first.<br>
> ><br>
><br>
> This is fine in principle, however I don't think we should push it<br>
> without considering the details (where the devil is apparently).<br>
> I am arguing that DB archiving should be re-done and is broken<br>
> conceptually (example below), and I think it would be suboptimal (to say<br>
> the least) to get it everywhere first and then fix it.<br>
><br>
> Just saying a hand-wavy "yeah, but once it's in Oslo we can fix it" is<br>
> wrong - especially for functionality that is younger than the time it<br>
> will likely take it to 'graduate' Oslo.<br>
<br>
</div>I'm not following this DB archiving debate closely enough to take a<br>
position either way, but ....<br>
<br>
I think what you're really arguing is that no other project should adopt<br>
this approach to DB archiving. I'm fine with saying that it shouldn't<br>
move into oslo-incubator if it will only be used in Nova.<br>
<br>
So - the debate to have is which projects are proposing to adopt this DB<br>
archiving strategy and whether it makes sense for them to adopt it as is<br>
and fix it up later, or adopt an entirely different approach.<br>
<br>
Cheers,<br>
Mark.<br>
<br>
</blockquote></div><br></div>