Re: [Maria-discuss] The future of Dynamic Columns

Note, you can use Flexvie.ws to materialize the get_column() output into another table, index that and use an inexpensive join to retrieve the data from the original table. It isn't a perfect solution, but it is a stop-gap to function based indexes. Sent from my iPhone > On Feb 1, 2015, at 3:

Re: [Maria-discuss] The future of Dynamic Columns

Hi, Tom! To sum this thread up: * clunky syntax is unfortunate, but that's what SQL is, that'll probably stay that way :( * A function to query a type of a value for a particular dynamic column, COLUMN_GET_SQL() as you call it, that should be easy to do. I've just created an issue for that

Re: [Maria-discuss] The future of Dynamic Columns

Hi, Roberto! On Jan 28, Roberto Spadim wrote: > i think a good start is "expression index​es" and after json syntax to SQL > language, and some new functions to handle json/etc > > CREATE INDEX name ON table ( some_function(field) ) > maybe dynamic column functions, or json functions? or any f

Re: [Maria-discuss] The future of Dynamic Columns

Hi Oleksandr!! :) Hi, Roberto! > >> at "value" parameter, COLUMN_CREATE know that we are using a STRING, but >> should be any other data type >> >> The *|as type|* part allows one to specify the value type. In most cases, >> this is redundant because MariaDB will be able to deduce the type of the

Re: [Maria-discuss] The future of Dynamic Columns

Hi, Roberto! On 29.01.15 15:55, Roberto Spadim wrote: 2015-01-29 12:34 GMT-02:00 Tom Worster >: I have one final technical question. It is for my understanding and does not reflect a problem I have as a user. The manual says: > The answer is: SQL is

Re: [Maria-discuss] The future of Dynamic Columns

one point... at the COLUMN_GET() at SELECT part of query mysql protocol, need one specific data type to send to client side this example: SELECT CONCAT('blabla', COLUMN_GET()), COLUMN_GET() 1st column: CONCAT return string, column_get isn't a problem here 2nd column: COLUMN_GET will retur

Re: [Maria-discuss] The future of Dynamic Columns

2015-01-29 12:34 GMT-02:00 Tom Worster : > I have one final technical question. It is for my understanding and does > not reflect a problem I have as a user. > > The manual says: > > > The answer is: SQL is a statically-typed language. The SQL interpreter > needs to know the datatypes of all expre

Re: [Maria-discuss] The future of Dynamic Columns

I'm going to respond to your previous two emails with a generality: It is sometimes better to optimize the software development process than the software's data processing. If this were not true, I would not be using this ORM at all and nobody should. But the converse is also clear: sometimes the

Re: [Maria-discuss] The future of Dynamic Columns

I have one final technical question. It is for my understanding and does not reflect a problem I have as a user. The manual says: > The answer is: SQL is a statically-typed language. The SQL interpreter needs to know the datatypes of all expressions before the query is run (for example, when one

Re: [Maria-discuss] The future of Dynamic Columns

2015-01-29 11:57 GMT-02:00 Tom Worster : > Hi Oleksandr, > > I'm going to stop bitching about Maria now. My needs are in fact met by > the current dyncol functions: > > - It's not so hard to write methods that generate CREATE_COLUMN() > expressions from a general data structure. > > - COLUMN_JSON(

Re: [Maria-discuss] The future of Dynamic Columns

2015-01-29 11:38 GMT-02:00 Tom Worster : > Hi Frederico, > > You identify three problems. > > 1. Developers are mostly ignorant of dynamic column or that they can solve > this problem. I agree. > hum, i will point some problems and ideas... normally developers don't think about how data is saved a

Re: [Maria-discuss] The future of Dynamic Columns

Hi Oleksandr, I'm going to stop bitching about Maria now. My needs are in fact met by the current dyncol functions: - It's not so hard to write methods that generate CREATE_COLUMN() expressions from a general data structure. - COLUMN_JSON() is just fine for all my reading purposes. I see no need

Re: [Maria-discuss] The future of Dynamic Columns

er and probably useful (something like a JSON_TO_DYNCOL function). > >Regards >Federico > > >------------------------ >Gio 29/1/15, Adam Scott ha scritto: > > Oggetto: Re: [Maria-discuss] The future of Dynamic Columns > A: "Oleksandr Byelkin"

Re: [Maria-discuss] The future of Dynamic Columns

, January 28, 2015 at 8:20 PM To: Oleksandr Byelkin Cc: Tom Worster , maria-discuss email list Subject: Re: [Maria-discuss] The future of Dynamic Columns Just wanted to add, any application that wants to store forms data without having to create a new table every time you create a new form could

Re: [Maria-discuss] The future of Dynamic Columns

rting data from JSON would be easier and probably useful (something like a JSON_TO_DYNCOL function). Regards Federico Gio 29/1/15, Adam Scott ha scritto: Oggetto: Re: [Maria-discuss] The future of Dynamic Columns A: "Oleksandr Byelkin"

Re: [Maria-discuss] The future of Dynamic Columns

yeap, i agree in my opnion... today without "expression index" to allow a faster search (on attribute or value) it's not possible to only use dynamic columns cause we get full table scan, today a second table with attribute-value should be necessary in this case to have a better performace what we

Re: [Maria-discuss] The future of Dynamic Columns

Just wanted to add, any application that wants to store forms data without having to create a new table every time you create a new form could benefit from dynamic columns. In the database design world, any design that is of the EAV (Entity-Attribute-Value) style would benefit from dynamic columns

Re: [Maria-discuss] The future of Dynamic Columns

Hi, Tom! On 29.01.15 01:12, Tom Worster wrote: [skip] And Maria promises us that we could use that expression to write the value back and the result will be the exact same thing. A sort of idempotency promise (kinda). This doesn't make the interface any less clunky (on the contrary) but I hav

Re: [Maria-discuss] The future of Dynamic Columns

On 1/28/15, 5:41 PM, "Oleksandr Byelkin" wrote: >Hi, Tom! > >On 28.01.15 23:01, Tom Worster wrote: >> While functions for getting and setting via json might be useful, I >> think they are peripheral to the core datatype problem here. >> >> The interface to dynamic columns in Maria is SQL. The in

Re: [Maria-discuss] The future of Dynamic Columns

Hi, Tom! On 28.01.15 23:01, Tom Worster wrote: While functions for getting and setting via json might be useful, I think they are peripheral to the core datatype problem here. The interface to dynamic columns in Maria is SQL. The internal datatypes are SQLish. We can be completely sure of wh

Re: [Maria-discuss] The future of Dynamic Columns

Hi Peter :) i will talk about what i used and what i consider interesting to have, 2015-01-28 19:25 GMT-02:00 Peter Laursen : > @Roberto. A comment to "i think it's a nice human readable format for > arrays/objects, nothing less nothing more". > > But why will you then need to **store** as JSON

Re: [Maria-discuss] The future of Dynamic Columns

t it put in. Tom From: Peter Laursen Date: Wednesday, January 28, 2015 at 4:25 PM To: Roberto Spadim Cc: Tom Worster , maria-discuss email list Subject: Re: [Maria-discuss] The future of Dynamic Columns @Roberto. A comment to "i think it's a nice human readable format for array

Re: [Maria-discuss] The future of Dynamic Columns

@Roberto. A comment to "i think it's a nice human readable format for arrays/objects, nothing less nothing more". But why will you then need to **store** as JSON? Could not something like "SELECT .. INTO JSON ..." do the trick? (with hindsight: "SELECT .. INTO XML ..." could have been implemented

Re: [Maria-discuss] The future of Dynamic Columns

i think a good start is "expression index​es" and after json syntax to SQL language, and some new functions to handle json/etc CREATE INDEX name ON table ( some_function(field) ) maybe dynamic column functions, or json functions? or any function deterministic (for example, NOW() function can't

Re: [Maria-discuss] The future of Dynamic Columns

Hi Sergei, Your reply complements Oleksandr's and is welcome. Your remarks about tepid user response to Dynamic Columns makes me want to reiterate the comments about better marketing my reply to Oleksandr. But you make even more clear that the flip side is very important. Users need to show their

Re: [Maria-discuss] The future of Dynamic Columns

Hi, Tom! On 28.01.15 18:04, Tom Worster wrote: Hi Oleksandr, Thank you for the response. It helps me make my decision by narrowing the options. I cannot help with money. My company doesn't have any (really! our market is non-commercial radio stations) but if the ORM extension turns out well th

Re: [Maria-discuss] The future of Dynamic Columns

Hi Oleksandr, Thank you for the response. It helps me make my decision by narrowing the options. I cannot help with money. My company doesn't have any (really! our market is non-commercial radio stations) but if the ORM extension turns out well then perhaps it helps some more people to use MDC.

Re: [Maria-discuss] The future of Dynamic Columns

some points 2015-01-28 14:06 GMT-02:00 Peter Laursen : > This discussion reminds me of 6-8 years back when XML was introduced in > MySQL ("LOAD DATA XML, "mysqldump --xml", XML functions (ExtractValue > etc.). It was a *big hype* at the time it was introduced. Now it seems to > be an almost forg

Re: [Maria-discuss] The future of Dynamic Columns

This discussion reminds me of 6-8 years back when XML was introduced in MySQL ("LOAD DATA XML, "mysqldump --xml", XML functions (ExtractValue etc.). It was a *big hype* at the time it was introduced. Now it seems to be an almost forgotten feature used by close_to_nobody. What should a JSON option

Re: [Maria-discuss] The future of Dynamic Columns

i will give some ideas , some could be stupid but that's just ideas... 1)could be nice a json language as data results, for example SELECT {'some array':'some value',column1:column2} AS column1 FROM some_table the result of {} is a string utf8, but well know as json format, the sql server just in

Re: [Maria-discuss] The future of Dynamic Columns

Hi, Tom! On Jan 27, Tom Worster wrote: > 2. In at least two places (one was here > ) > I've read text with the implied meaning, "we may improve such-and-such > about MDC if and when people start actually using it." While

Re: [Maria-discuss] The future of Dynamic Columns

Hi! On 27.01.15 16:39, Tom Worster wrote: [skip] 2. In at least two places (one was here ) I've read text with the implied meaning, "we may improve such-and-such about MDC if and when people start actually using it."

Re: [Maria-discuss] The future of Dynamic Columns

On 12/26/14 I posted here I posted the question to this mailing list: *Dynamic columns support in libmaria client library?* *This page https://mariadb.com/kb/en/mariadb/documentation/nosql/dynamic-columns-api/ does not

Re: [Maria-discuss] The future of Dynamic Columns

i use dynamic columns without problem, it don't have a good future cause it's only a lot of function to encode/decode data, in other words, the future is the today present + some new features to easly handle data or optimize space or optimize cpu/memory use make sure you are using a good encode sy

[Maria-discuss] The future of Dynamic Columns

I've been excited about the potential uses of Maria's Dynamic Columns (MDC) since I first read about the them. Now I am starting a new application development and want to use MDC. It's a server-side PHP webapp using the Yii 2.0 MVC framework. These days, for typical webapp pages, I seldom write SQ