Как я могу собрать SQL с объектно-ориентированным Perl?
Пожалуйста, замените ваш код следующим:
Главный экран
class HomeScreen extends React.Component {
//initial
constructor(props) {
super(props);
this.state = {
isReady: false,
myMenu: '????',
menutext: '',
randomArray: ['a', 'b', 'c'],
};
}
render() {
return (
<View style={[styles.mainContainer]}>
<DetailsScreen menuListAA={this.state.randomArray} />
<Button
label="Show all menu"
onPress={() => {
/* 1. Navigate to the menu page route with params */
this.props.navigation.navigate('Details', {
itemId: 0,
otherParam: 'Show all menu',
});
}}
/>
</View>
Сомнения подробно : заменить View на [113 ] компонент
class DetailsScreen extends React.Component {
constructor(props) {
super(props);
this.state = {
}
}
static navigationOptions = {
title: 'All menu',
};
loadMenuList() {
const allMenuList = this.props.menuListAA;
return allMenuList.map((item, index) => <Text key={index}>{item}</Text>);
}
render() {
return (
<ScrollView>
//change View with Text as view cannot render characters and error says the same
<Text style={styles.row}>{this.props.menuListAA}</Text>
<Button
label="Go back"
onPress={() => this.props.navigation.goBack()}
/>
</ScrollView>
);
}
}
const RootStack = createStackNavigator(
{
Home: HomeScreen,
Details: DetailsScreen,
},
{
initialRouteName: 'Home',
}
);
const AppContainer = createAppContainer(RootStack);
export default class App extends React.Component {
render() {
return <AppContainer />;
}
}
8 ответов
Вы хотите посмотреть на Fey. Я начал использовать его несколько месяцев назад на задании, и в то время как реализация все еще имеет грубые углы из-за молодого возраста, идея позади него тверда. F.ex., возьмите запрос, слегка адаптированный из руководства:
my $user = $schema->table( 'user' );
my $q = Fey::SQL
->new_select
->select( $user->columns( 'user_id', 'username' ) )
->from( $user );
Теперь Вы могли записать функцию как это:
sub restrict_with_group {
my ( $q, $table, @group_id ) = @_;
my $group = $schema->table( 'group' )->alias;
$q
->from( $table, $group )
->where( $group->column( 'group_id' ), 'IN', @group_id );
}
Это добавит внутреннее объединение от user кому: group а также a WHERE состояние. И вуаля, можно записать следующее в основной программе:
restrict_with_group( $q, $user, qw( 1 2 3 ) );
Но это restrict_with_group функция будет работать на любой запрос это, которое имеет внешний ключ к group таблица! Для использования его Вы передаете запрос, который Вы хотите ограничить и таблица, на которую Вы хотите ввести ограничение, а также идентификаторы группы, которыми Вы хотите ограничить его.
В конце Вы говорите $q->sql( $dbh ) и Вы возвращаете строку SQL, представляющего запрос, который Вы создали в $q объект.
Так в основном Fey дает Вам абстрактные возможности, что собственный SQL отсутствует. Можно извлечь допускающие повторное использование аспекты из запросов и упаковать их как отдельные функции.
Если Вы не хотите ORM, но Вы хотите собрать SQL от битов без прямой обработки строк / конкатенация, смотреть на Fey, которая может сделать то, что Вы хотите.
Обновление: ответ Aristotle Pagaltzis намного лучше. Он на самом деле дал примеры того, на что похожа Fey и как это может помочь.
Не пишите свой собственный ORM. Используйте что-то как DBIx:: Класс.
Все эти проблемы, которые Вы упоминаете, были решены, и реализация, протестированная в тысячах других приложений. Придерживайтесь записи Вашего приложения, не повторно реализовывая библиотеки. Вы не могли бы на самом деле использовать DBIC в своем приложении, но необходимо посмотреть на его подход реализации; особенно, как это инкрементно создает ResultSets (которые не являются наборами результатов, но скорее задерживаются запросы).
От чистого кодирования точки зрения - у Вас есть длинная и сложная часть кода Ваших рук. Вам не нравится он. Почему? Я могу только предположить, что существует некоторое дублирование кода там. Иначе, чему не должно нравиться? Так, осуществите рефакторинг его для устранения дублирования... Я знаю, что это звучит банальным, но так как Вы не отправляете код, трудно быть более конкретным. Может быть имеют объект, который имеет методы для от, где и вставляют пункты, так, чтобы инфраструктура SQL не была дублирована? Я просто не знаю, что сделать, точно, но устранение дублирования является ключевым.
Если я не неправильно понимаю, это кажется, что ETL (Извлекает/Преобразовывает/Загружает) приложение, которое не выяснило для разделения трех этапов.
Если выходная модель является только таблицей, или два затем Вы, вероятно, точно также от использования SQL. Иначе, и особенно если существуют отношения между таблицами, Вы вставляете в, достойный ORM должен упростить вещи.
Беря идею с 50 состояниями, Вы не можете действительно убежать от наличия 50 процессов "извлечения", надо надеяться, с библиотекой общих стандартных программ. Я принялся бы за решение проблемы один входной источник за один раз, осуществив рефакторинг, поскольку я добавил новые, но стараться инкапсулирует переменные части так, чтобы я знал точно, где изменения должны будут быть внесены, когда поставщик изменит их формат.
Часть "преобразования" не должна быть слишком обременительной: просто возьмите то, что Вы получили, и подготовьте его к выводу.
Я думаю, что Вы описываете динамический SQL - создание запроса программно во времени выполнения. Это - типичная функция Объектных Реляционных Картопостроителей, таких как LINQ к SQL и LLBLGenPro, для именования некоторых. Создание того не является никакой небольшой задачей.
Обычно ORMs воплощают язык SQL. Вы пишете своего рода "Объектную модель документа (DOM) SQL", которая позволяет Вам создавать SQL-запросы программно путем представления их (например), как объекта "Запроса". Вы затем устанавливаете свойства на объекте Запроса, такие как Набор столбцов, набор Таблицы и набор Соединения (это просто примеры одного подхода.) Результатом была бы строка запроса SQL, выставленная как свойство объекта Запроса.
Необходимо также позволить объекту Запроса прочитать определение схемы источников данных. Вы упоминаете, что Ваш оператор Where зависим от типа. Ваш ассемблер SQL должен поэтому смочь прочитать схему и создать пункт соответственно.
Это может быть излишеством для Вашего случая. Я думаю, что фундаментальный вопрос, Вы абсолютно требуете динамических SQL-запросов, или есть ли менее сложная опция, которая удовлетворит Ваши требования?
Это кажется мне как подход, который Вы проявляете для решения этой проблемы, возможно, должен посмотреться на. У Вас в настоящее время есть несколько источников данных, которые необходимо рассматривать, как будто это был единственный источник данных. Итак, почему сохраняют их как отдельные источники данных?
В зависимости от того, как часто обновляются данные (или рассмотрение производительности, как часто к этому получают доступ), Вы могли возможно сделать комбинацию данных во временный источник данных, такой как SQLite. Если Ваши данные из каждого состояния имеют переводчика, который возьмет его от формата A до Вашего распространенного формата в таблице SQLite, то можно использовать выбор методов получить доступ к нему.
Этот метод также допускает гибкость, поскольку Вашему доступу к данным нужно, может измениться. Например, если Вас задают вопрос, "Сколько светлых драйверов имело талоны о превышении скорости в каждом состоянии?". База данных SQLite может сделать это с единственной командой, в то время как другие решения, вероятно, потребовали бы возврата ряд данных, которые затем должны быть проанализированы, сгруппированы и установлены для вывода.
Если Вы не хотите иметь дело с ORM, у меня часто есть код как это:
my (@columns,@tables,@wheres,@order_bys,@values);
... # Add value to those variables as needed, using push.
... # use ? for variables to be quoted
# Build SQL statement
my $sql = "select ".join(",",@columns).
" from ".join(",",@tables).
" where ".join(" and ",@wheres).
" order by ".join(",",@order_bys);
my $sth = $dbh->prepare($sql);
$sth->execute(@values);
Простой, никакая потребность в ORM, очень настраиваемом. Плюс, я всегда нахожу ORM слишком тяжелый для объема данных, с которыми я имею дело, но это - другой предмет.