pbxt-discuss team mailing list archive
-
pbxt-discuss team
-
Mailing list archive
-
Message #00083
Re: Row buffers and Object (was Re: free_table_share() != drizzle)
On Fri, 21 May 2010 17:41:05 -0700, Brian Aker <brian@xxxxxxxxxxx> wrote:
> On May 21, 2010, at 2:31 AM, Paul McCullagh wrote:
>
> > My problem is that the val_ methods are hard-coded to reference
> > record[0].
(see my previous mai) but they're not. it just looks that way.
> My plan is to add a second set of Field that will correspond to the
> second row (got any handy names!). That way we won't need a hack in
> order to access them.
I don't think we need this, the move_field_offset() calls work
currently, although they API is rather wrong, we could fix that.
> > Instead, I suggest a "Row" object, into which I can plug the start of the row buffer. Then we would have:
> > doInsertRecord(Row *row_object)
> > The Row object knows everything about the row and can be used to access the fields.
>
> This sounds fine, and essentially what we have at the moment (but no knowledge of row2).
>
> I hate calling them row1 and row2 though. Any ideas on that? Do you
> want them handed to you? Should we encapsulate so that you can't
> access them unless they are passed in?
I think we should move that way. record[] being private. Engines just
get the buffers as parameters - the buffers could be anywhere.
If an engine needs a temporary buffer for something, it can always ask
for one.
> One thing I would disagree on though is the setBuffer(), that removes
> all encapsulation on the fields (which is bad, since over time those
> do change). We have one format for Decimal right now, if we change
> that and have no version information we take the chance we might push
> data back and forth which would not be compatible.
We have that already. In fact, we have worse than that, most places just
go and poke into the format directly, not using the Field objects at
all. It's been a rather concentrated effort to not do this in
embedded_innodb - it certianly would have made some code easier.
This is how you get a ptr to a VARCHAR string so you can use it to
search for things in your engine:
String str;
(**field).setReadSet();
(**field).val_str(&str);
err= ib_col_set_value(tuple, colnr, str.ptr(), str.length());
All of the methods in Field_varstring don't do what you want otherwise
(or you get to make a copy... and that sucks).
--
Stewart Smith
References
-
free_table_share() != drizzle
From: Brian Aker, 2010-05-08
-
Re: free_table_share() != drizzle
From: Paul McCullagh, 2010-05-10
-
Re: free_table_share() != drizzle
From: Brian Aker, 2010-05-11
-
Re: free_table_share() != drizzle
From: Paul McCullagh, 2010-05-14
-
Re: free_table_share() != drizzle
From: Brian Aker, 2010-05-14
-
Re: free_table_share() != drizzle
From: Paul McCullagh, 2010-05-14
-
Re: free_table_share() != drizzle
From: Brian Aker, 2010-05-14
-
Re: free_table_share() != drizzle
From: Paul McCullagh, 2010-05-17
-
Re: free_table_share() != drizzle
From: Brian Aker, 2010-05-17
-
Re: free_table_share() != drizzle
From: Paul McCullagh, 2010-05-20
-
Re: free_table_share() != drizzle
From: Brian Aker, 2010-05-20
-
Row buffers and Object (was Re: free_table_share() != drizzle)
From: Paul McCullagh, 2010-05-21
-
Re: Row buffers and Object (was Re: free_table_share() != drizzle)
From: Brian Aker, 2010-05-22