|
Pages: [1]
|
 |
|
Author
|
Topic: rowid (Read 560 times)
|
cedric
Guest
|
 |
rowid
« on: February 26, 2004, 10:09:52 AM » |
|
Hello,
I understand that rowid is based on the order datas have been saved on disk.
I mean that if I open a table with : 'db-select/order/desc * my-table ID' then 'db-select/where * my-table [rowid = 1]' will not return the record with the highest ID. but the first that have been saved on disk.
Of course, this would have been more like a "recordset mechanism". But it would be really smart to have a "rowid" based on the query that have been last submitted.
So, Ashley, do you think this could happen in a next rebDB release?
Bye,
Cedric.
|
|
|
|
|
Logged
|
|
|
|
|
Ashley
|
 |
rowid
« Reply #1 on: February 26, 2004, 04:27:56 PM » |
|
A "recordset mechanism" is fine in a single-user environment, but in a multi-user (or multi-process) environment *without transaction support* each statement has to be evaluated in isolation, so the current implementation won't be changing soon. Note that if you just want to get the last row, then the following will do the trick: db-select/where * my-table [rowid = last]
You can also get the last n rows (reverse sorted if desired) using: db [select * from my-table where [rowid between 6 last] order by id desc]
Although being able to replace the "6" with "(last - 4)" would be better. Food for thought.
|
|
|
|
|
Logged
|
|
|
|
Guest
Guest
|
 |
rowid
« Reply #2 on: February 27, 2004, 03:06:26 AM » |
|
I didn't meant a full "recordset mechanism".
I was wondering that while a query is done, there could be, perhaps, a function that would build "dynamically" a row identificator based on the query.
lets name that "dynamically builded" row "row_x" and use the same populate table "my-table" in your rebDB quick-guide.
we do: db-select * my-table then doing: db-select/where id my-table [row_x = 1] would return [1] But if we do: db-select/order/desc * my-table id then doing db-select/where id my-table [row_x = 1] would return [10]
That is.
cedric.
|
|
|
|
|
Logged
|
|
|
|
|
Ashley
|
 |
rowid
« Reply #3 on: February 27, 2004, 04:26:06 AM » |
|
Ah, I think I understand now. While rowid acts upon rows in the table *in the order they are stored*, row_x acts upon rows *in the order they are retrieved*? So: db [select id from my-table where [rowid = 2]]
will return "2", while: db [select id from my-table where [row_x = 2] order by ID desc]
would return "9". Correct? I havn't come across this behaviour in the databases I've worked with, what DB are you using that does this? Is the reqirement for row_x really just a requirement for a LIMIT clause (so you can "page through" a large number of rows)? Do you have a link to any online doco that describes its use?
|
|
|
|
|
Logged
|
|
|
|
Guest
Guest
|
 |
rowid
« Reply #4 on: February 27, 2004, 06:58:24 AM » |
|
Yes, you catch what I was meaning. Well, what make me thing of this behavior is that when first submiting a query the whole datas are load into memory until db-close is called. Then, I would expect that datas loaded in memory would reflect the query I last called. Imagine I need to display the last 5 rows of "my-table" in reverse order by date. I would do something like: m: db-select/order/desc [date note] my-table date i: 1 forskip m 2 [print [first m second m]if i = 5 [break] i: i+1]
No let say that this row_x exists. I would do: db-select/order/desc * my-table date ; there's now datas in memory reflecting the query above for i 1 5 1 [ print [db-select/where [date note] my-table [row_x = i] ]
But, I admit, I'm not a database guru and there's proprably no database common fundamentals in what I'm saying. cedric.
|
|
|
|
|
Logged
|
|
|
|
|
Ashley
|
 |
rowid
« Reply #5 on: February 27, 2004, 09:27:42 PM » |
|
Well, what make me thing of this behavior is that when first submiting a query the whole datas are load into memory until db-close is called. Then, I would expect that datas loaded in memory would reflect the query I last called.
Not quite. When a table is first referenced the entire contents are memory-mapped. Subsequent statements then use a buffer to store results, but subsequent statements (perhaps from a different user / process) will overwrite that buffer with their own results. In short, if you want a statement to use the results of a previous statement then you have to save these intermediate results to be able to use them. But, I admit, I'm not a database guru and there's proprably no database common fundamentals in what I'm saying.
Yes and no.  In many databases, in addition to using 'rowid in the 'where clause 'rowid can be used as a pseudo-column, which lets you write: cursor: db [select [rowid ID] from my-table order by ID desc]
then repeat i 5 [ db compose/deep [select * from my-table where [rowid = (i * 2 - 1)]] ]
I will be adding this feature to v1.2 (due early March) and it should address the kind of issues you have.
|
|
|
|
|
Logged
|
|
|
|
|
|
Pages: [1]
|
|
|
 |
News: 01-09-08 Alpha version of REBOL 3 has been released!
2235 Posts in 583 Topics by 1757 Members
Latest Member: Xzycdysz
|