AW: AW: [DIRECT-L Valentina 2.0. -- What is your 3 DREAMfeatures? // XML

[Florian Bogeschdorfer]

Hi Ruslan!


> > 
> > The result is a new cursor having all records from Cursor 1 
> and 2. I 
> > know this can be easily done with SQL but what if the 
> SELECT criteria 
> > is much larger?
> 
> So what? 
> 
>     SELECT ............................
>         UNION
>     SELECT ..............................
> 

What if you don't know the query anymore? 
And think about the user(my customer): he gets a quite simple interface to
search his db. He does not know SQL and you don't want to make a huge and
complicated interface. However he could do quite simple queries and then
merge or subtract quite easily...

> > Also what about speed (we discussed that already, 
> remember?) It would 
> > moreover be so elegant. Also maybe you have a large cursor and you 
> > could easily subtract step by step.
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Great words. Actually not easy.
> All operations on cursor will require at first TOTAL SORTING 
> by all columns.
> Otherwise you do not have way to COMPARE records in effective way.
> 

I agree if it comes to multiple tables. But if we talk about a single table
(which I would need it for at the moment), all you need is a unique record
ID. Add, merge and subtract would be very simple...

 

> What you say can be made in this way:
> 
> 1) you do SELECT, but not just into cursor, but into new TMP Table
> 
>         SELECT ... INTO Table tmp_t1
>         SELECT ... INTO Table tmp_t2
> 
> Now you have the same task. TABLES.
> 
> Just by definition cursor is -- RESULT Table.
> We should not use it so flexible as you offer.
> 
> Now having tmp_t1, you can tell,
> 
>     SELECT * FROM TMP_t1
>    EXCEPT 
>     SELECT * FROM tmp_T1 WHERE f = 'r'

I understand. It may help in some cases, but I think the merge/add thing is
kind of more natural. Also look about the "save" topic later on
> 
> 
> > I would also like so save cursors to disk. Make a query, need the 
> > cursor again in some days, so I save it to disk. 
> Interesting, because 
> > if I would repeat the query in a week, it might not be the same 
> > because of changed data. Right now, I save a list with my 
> own record 
> > Ids to disk, but I can not make it a cursor anymore...I have to go 
> > through the list step by step if I need additional data.
> 
> Yes, this feature is interesting.
>     ability store cursor to disk, and re-create it back AS CURSOR.
> 
> I want EXPLAIN potential problems:
> * very often our cursor do not create TMP table, just keep 
> pointers on original table.
> * I think we cannot SAVE this pointers to disk, because 
> records can be deleted, and replaced by new, so pointers will 
> be quite wrong.

I don't think this is a problem. If you store a cursor to disk I would store
the unique record Ids. Since RecId from Valentina is reused, it must be
something else. Now if I store a cursor, I know very well that it might be
outdated tomorrow, but never mind. You could load the cursor, recreate it
according to the saved Ids (this is one table again!) and maybe issue an
event that xx records are no longer available. This would be sooooo smooth!!

 
> Only way -- create TMP table -- as result of such SAVING.
> This means total coping of data of all records of cursor.
> You still want such feature?  :-)

Yes, still interesting. Imagine a company making a mailing again. It's large
and then 100000 letters should be spread over 4 weeks, say 25000 a week. Now
data might change in this 4 weeks, but your mailing should ignore this. You
need a quite complicated workaround for this. But if I could store the TMP
table even with all the date it would be brilliant - just load the cursor
and continue.

So I think there should be two ways to save cursors: tmp table with all data
and cursor with Ids only. I would love this.

Also this would be a way to share cursors. Right now client2 can not access
a cursor from client1 right? Even if it is serverside. With save/load this
would work.



Best regards, Florian