From javier.gutierrez at web.de Wed Dec 11 02:16:46 2024 From: javier.gutierrez at web.de (Javier Gutierrez) Date: Wed Dec 11 02:17:05 2024 Subject: [odb-users] Getting the datatype length Message-ID: <00e601db4b9c$a3c10940$eb431bc0$@web.de> Hi Boris, I am getting the error "Data too long for column" which of course means I have to shorten the data to the column length before persisting. Now, let's say I define my column this way: #pragma db value_type("VARCHAR(255)") Is it possible to somehow retrieve the datatype length from the definition? (I'd like to prevent hardcoding all these lengths in my code.) Or to force ODB to truncate the values to that length? Thanks in advance. Best regards, Javier Gutierrez From boris at codesynthesis.com Thu Dec 12 08:29:35 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 12 08:28:32 2024 Subject: [odb-users] Getting the datatype length In-Reply-To: <00e601db4b9c$a3c10940$eb431bc0$@web.de> References: <00e601db4b9c$a3c10940$eb431bc0$@web.de> Message-ID: Javier Gutierrez writes: > I am getting the error "Data too long for column" which of course means I > have to shorten the data to the column length before persisting. > Now, let's say I define my column this way: > > #pragma db value_type("VARCHAR(255)") > > Is it possible to somehow retrieve the datatype length from the definition? > (I'd like to prevent hardcoding all these lengths in my code.) No, I can't think of any way to get to this information. In fact, this information (the 255 limit) is not even present in the generated code. > Or to force ODB to truncate the values to that length? There is no out-of-the box support for this but you could define a custom string type and provide a mapping for it that would truncate the string before persisting. Something along these lines: #pragma db value type("VARCHAR(255)") class varchar255: public std::string { public: using string::string; }; #pragma db map type(varchar255) as(std::string) \ to((?).substr (0, 255)) \ from(varchar255 (?)) (You could also change the default std::string mapping to truncate if it's always mapped to VARCHAR(255) in your application. For that you would need to specialize odb::value_trait.) From becoggins at hotmail.com Fri Dec 20 12:32:28 2024 From: becoggins at hotmail.com (Brian Coggins) Date: Fri Dec 20 12:32:50 2024 Subject: [odb-users] WITH Queries in Views In-Reply-To: References: Message-ID: <4CBED1B2-0A9A-4B80-8BC6-EBFC060BCDF4@hotmail.com> Hey Boris, I?m provisioning a new machine, and was hoping to install on it the 2.5.0-b.28.20240731125623.c6da3d9c4e9f version that you put together last summer (see below), but it does not seem to be live on the server any more: using queue.stage.build2.org/1/alpha, build2 downloads 2.5.0-b.27. Any chance you could put the updated version back up? Or if it has moved, could I get a new URL? Thanks, Brian On 31 Jul 2024, at 09:17, Boris Kolpackov wrote: Brian Coggins writes: Yes, it tries to guess whether it's a complete query or the WHERE clause by checking if the query starts with one of the known keywords (like SELECT). I have a TODO item to recognize some additional database- specific keywords (like WITH). I?ve run into this limitation again, this time in the context of a WITH RECURSIVE ? query that I don?t think can be accomplished any other way. I upgraded to ODB 2.5.0-b.27 but it seems the issue is still there. Any chance we might be able to get a patch to loosen up these restrictions? Ok, I went ahead and added WITH as a recognized SELECT prefix (I see it's also supported by SQLite). Plus I've added the /*SELECT*/ prefix as a hint that what follows is a SELECT-like query (this is similar to the /*CALL*/ hint we use to distinguish procedure calls in PostgreSQL, which uses SELECT for everything). If you want to give it a try, I've published the snapshot packages here: https://queue.stage.build2.org Simply replace: https://pkg.cppget.org/1/beta with: https://queue.stage.build2.org/1/alpha in the bpkg commands when building ODB. Let me know if there any issues. From boris at codesynthesis.com Tue Dec 24 02:01:02 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 24 01:59:55 2024 Subject: [odb-users] WITH Queries in Views In-Reply-To: <4CBED1B2-0A9A-4B80-8BC6-EBFC060BCDF4@hotmail.com> References: <4CBED1B2-0A9A-4B80-8BC6-EBFC060BCDF4@hotmail.com> Message-ID: Brian Coggins writes: > was hoping to install on it the 2.5.0-b.28.20240731125623.c6da3d9c4e9f > version that you put together last summer (see below), but it does not > seem to be live on the server any more [...] Any chance you could put > the updated version back up? That version was a development snapshot and it won't be easy to put that back. But I've published the latest snapshot to: https://queue.stage.build2.org/ BTW, we plan to release 2.5.0 final in Jan. Not sure if you would prefer to wait for that. From becoggins at hotmail.com Tue Dec 24 16:06:03 2024 From: becoggins at hotmail.com (Brian Coggins) Date: Tue Dec 24 16:06:25 2024 Subject: [odb-users] WITH Queries in Views In-Reply-To: References: <4CBED1B2-0A9A-4B80-8BC6-EBFC060BCDF4@hotmail.com> Message-ID: > That version was a development snapshot and it won't be easy to put that > back. But I've published the latest snapshot to: > > https://queue.stage.build2.org/ > Thank you! That was just what I needed to get this machine running. > BTW, we plan to release 2.5.0 final in Jan. Not sure if you would prefer > to wait for that. Looking forward to 2.5.0! I will update when it comes out. Brian